SAP NPM Supply Chain Attack. Legacy Detect-and-Respond Tools Leave Your Doors Wide Open

AccuKnox Proactive Runtime delivers Zero Trust Security

On April 29, 2026, researchers at Aikido Security found that four SAP npm packages — @cap-js/sqlite, @cap-js/postgres, @cap-js/db-service, and mbt — had been poisoned with a payload that harvested npm tokens, GitHub credentials, SSH keys, AWS/Azure/GCP secrets, and Kubernetes configs from every machine that ran npm install. No clicks required. The attack leveraged credentials harvesting through environment variables in the proc filesystem to extract sensitive data that developers unwittingly exposed during routine installations. 

Dubbed “Mini Shai-Hulud” by the threat group TeamPCP, the attack rode npm’s preinstall hook to download the Bun JavaScript runtime and execute an obfuscated 11 MB credential stealer. Stolen data was encrypted and exfiltrated to GitHub repos created under the victim’s account — then the stolen npm tokens were used to poison more packages, turning every compromised developer into the next attack vector.

Most security tooling would have watched the whole thing happen.

The Problem With “Detect and Respond”

Most endpoint and workload security tools follow the same playbook: observe suspicious behavior, generate an alert, trigger a response. Kill the process. Quarantine the file. Page the SOC.

Against this attack, that playbook collapses. Here is why.

The credential stealer reads from well-known paths (~/.ssh/, ~/.aws/credentials, ~/.npmrc)  and performs credentials harvesting through environment variables in the proc filesystem via /proc/self/environ, also targeting Kubernetes service account tokens at /run/secrets/kubernetes.io/serviceaccount/ — encrypts the data, and pushes it to a remote repository. The entire chain completes in seconds. By the time a detection-based tool flags the anomaly and spins up a response, the credentials are already gone. The attacker has your npm token. The worm is publishing poisoned packages under your name.

Detection after exfiltration is a postmortem, not a defense.

Three Points of Enforcement That Actually Matter

Stopping this attack requires controls that operate before execution completes — not after. That means enforcement at the kernel level, where system calls are intercepted and policy decisions are made inline, before the operation returns a result.Here is how AccuKnox’s runtime security, powered by KubeArmor and enforced through eBPF and Linux Security Modules, addresses each stage of the kill chain.

1. Credential Harvesting: Blocked at File Access

The payload’s first objective is reading credential files and performing credentials harvesting through environment variables in the proc filesystem. SSH keys. Cloud provider configs. Kubernetes service account tokens. npm and GitHub auth tokens stored on disk or exposed in environment variables. 

AccuKnox enforces file access policies at the kernel level using LSM hooks. Policies define exactly which processes are authorized to read sensitive paths like:/etc/shadow,  /run/secrets/kubernetes.io/serviceaccount/, ~/.ssh/, and credential configuration files. AccuKnox also blocks unauthorized access to /proc/self/environ and similar proc filesystem paths where credentials harvesting through environment variables would occur. Any unauthorized process — including a freshly downloaded Bun runtime executing an obfuscated JavaScript payload — gets a hard denial at the SYS_OPEN syscall. The read never completes. The credentials stay where they are.

This is not just a log entry; it is an enforcement action that happens before the file contents reach the attacker’s code.

2. Unauthorized Process Execution: Blocked at Spawn

The attack’s delivery mechanism downloads the Bun runtime and uses it to execute execution.js. In a default-allow environment, this works because nothing stops an unknown binary from running.

AccuKnox’s process whitelisting policies flip the model. In an enforced workload, only explicitly authorized processes — the application server, its known dependencies, specific system utilities — are allowed to execute. Everything else is denied at the SYS_EXECVE syscall.

The downloaded Bun binary? Blocked. The setup.mjs loader trying to spawn it? Blocked. The attacker’s entire execution chain dies at the first unauthorized process spawn, before a single credential file is touched.

3. Preemptive Mitigation: Why Seconds Matter

The distinction between inline mitigation and detect-and-respond is not academic when exfiltration happens in seconds.

AccuKnox enforces policies at the kernel layer — through Linux security modules such as AppArmor and BPF-LSM — meaning policy decisions execute at the same privilege level as the operating system itself. There is no userspace agent racing against the attacker. There is no window between detection and response. The syscall is intercepted, the policy is evaluated, and the operation is allowed or denied before it returns.

Post-attack remediation (killing a process after it has already run) gives the attacker a window to disable logging, encrypt data, or exfiltrate secrets. Inline mitigation closes that window entirely.

What This Means for Your CI/CD Pipelines and Supply Chain Security

1. The SAP npm attack specifically targeted CI/CD environments because that is where credential density is highest and oversight is thinnest. Build runners hold npm tokens, cloud provider credentials, GitHub Actions secrets, and Kubernetes configs — all in memory or on disk, all accessible to any process running in that environment.
2. If your CI/CD runners operate in Kubernetes, AccuKnox policies can enforce the same zero trust posture there: whitelisted build processes only, credential file access restricted to authorized tooling, and network policies that prevent exfiltration to unauthorized endpoints.
3. If your runners are VMs or bare metal, KubeArmor supports non-Kubernetes environments with the same eBPF and LSM enforcement model.
4. The principle remains constant: default-deny execution, least-privilege file access, and enforcement that operates at kernel speed.

The Bottom Line

Supply chain attacks that weaponize trusted package managers are not going away. The TeamPCP group behind this campaign has hit Bitwarden, Checkmarx, and now SAP — and the worm-like propagation mechanism means every compromised developer becomes a vector for the next attack.

Detection tools will tell you what happened. Runtime enforcement stops it from happening. When credential exfiltration completes in seconds, that distinction is the entire ballgame. Book a demo if you’d like to see runtime enforcement in action. 

FAQs