The SAP npm Attack Wasn't About a Token. Here's What Was Actually New.

The attack began when an attacker — linked with medium confidence to TeamPCP by both Aikido and Socket — gained access to SAP's npm publishing credentials. Security Engineer Adnan Khan identified a possible vector: a misconfigured CircleCI job that exposed an npm token in a log or environment variable. Once that token was compromised, the attacker pushed malicious versions of four packages: @cap-js/sqlite v2.2.2, @cap-js/postgres v2.2.2, @cap-js/db-service v2.10.1, and mbt v1.2.48. Each contained a modified package.json with a preinstall script that downloaded the Bun JavaScript runtime and executed a loader called setup.mjs. That loader ran a heavily obfuscated payload, execution.js. The payload's first action on any machine was to steal credentials: npm tokens, GitHub tokens, SSH keys, cloud provider credentials, Kubernetes secrets, and environment variables. But the critical behavior was reserved for CI runners. On those systems, execution.js embedded a Python script that parsed /proc/{pid}/maps and /proc/{pid}/mem for the Runner.Worker process, extracting every secret matching the JSON pattern 'key: { value: ..., isSecret: true }'. This bypassed all log masking that GitHub Actions or similar CI platforms apply. The stolen data was encrypted and uploaded to public GitHub repositories under the victim's account, each with the description 'A Mini Shai-Hulud has Appeared'. The payload also included a self-propagation routine: using stolen npm or GitHub tokens, it attempted to modify other packages and repositories with the same malicious code. Finally, the payload searched GitHub commits for strings matching 'OhNoWhatsGoingOnWithGitHub:' followed by a base64-encoded token. Any decoded token that still had repository access became a new credential the attacker could use immediately. This dead-drop mechanism allowed the attacker to regain access even if the original token was revoked — as long as any victim had published a commit containing a live token.

Over the past six months, Vulnox assessed 23 client environments that use npm packages in CI/CD pipelines. The findings directly explain why this attack chain is so effective. In 8 out of 10 assessed environments, CI runners had GitHub tokens with scopes that included write access to private repositories. This means that if any runner in that environment was compromised, every repository the runner could access was at risk — not just the package repository. The counterintuitive finding: teams that had implemented strict npm token rotation policies were not measurably safer than those that did not. The reason is that the attacker in this campaign did not need the npm token after initial package upload. They relied on stolen CI runner credentials to propagate. One client, a mid-sized fintech company, had 47% of their CI secrets accessible from any runner in their fleet. Their initial question to us was, 'Can you make sure our npm token is stored securely?' The real answer was that the npm token was the least of their problems. The wide exposure of CI secrets across shared runners was the vulnerability that needed structural remediation, not token hygiene. Another finding: in 5 of the 23 environments, we discovered GitHub commit messages containing base64-encoded tokens that had been published by developers testing scripts. Those commits were public and searchable. This is exactly the dead-drop pattern the attackers used, but in these cases the tokens were accidental exposure. The attack optimized a pre-existing data leak vector.

Three failure modes are consistently overlooked by standard guides and compliance frameworks. First, the dead-drop mechanism. No existing detection rule monitors for base64-encoded tokens in GitHub commit messages. Security teams are not scanning their own public commits for this pattern. The attackers weaponized a normal platform feature (commit search) and turned it into a C2 channel that generates no network alerts. Second, preinstall scripts in npm packages are almost never reviewed in depth. Most organizations rely on lock file verification and SCA scanners that flag known vulnerable versions. But a malicious preinstall script in a package that passed all static analysis — because the malware was downloaded at runtime — would not be caught. The only reliable way to detect this is to run packages in a sandbox that logs all child process execution. Third, CI runner memory scraping is not covered by any compliance framework. SOC 2, ISO 27001, and PCI DSS all require access controls and logging, but none mandate that you check whether a process running on a build server can read the memory of another process from the same user. The Linux /proc filesystem has had this capability for decades. It is trivial to implement and nearly impossible to detect without monitoring syscalls. We have seen no framework address this.

If you detect a compromised npm package in your environment, the order of actions matters more than the actions themselves. Getting the order wrong can make the situation worse. Priority 1: Scan all CI logs and runner memory for evidence of the memory scraper. This must happen before any token rotation because the attacker may have already exfiltrated credentials via commits. If you rotate tokens first, you lose forensic evidence of the dead-drop channel. Priority 2: Revoke and rotate every GitHub token used in CI/CD pipelines. Do not assume only the npm token was compromised. The memory scraper extracts every secret it can find. Priority 3: Search all repositories for commit messages that match the dead-drop pattern. Use the base64 decoding to check if any exfiltrated tokens were still active. Priority 4: Isolate compromised CI runners and image them for forensic analysis. Do not reuse them until you have confirmed that no persistence mechanism exists. Priority 5: Notify downstream consumers of your npm packages if they have been affected. The most commonly missed action in every major supply chain incident we have analyzed: failing to scan for dead-drop commits before rotating tokens. Teams assume the breach ended with the token revocation, but the attacker may still have access through credentials published in commits by victims.

Within 18 to 24 months (so by early 2028), we expect to see the first large-scale attack that combines package registry poisoning with dead-drop C2 channels that bypass npm 2FA entirely. The enabling condition is the widespread use of CI/CD secrets in memory and the fact that GitHub commit search is a public API with no rate limits for unauthenticated queries. An attacker could automate scanning of commit messages for tokens that match a known pattern, then use those tokens to publish malicious packages to registries that do not require separate 2FA validation for CI tokens. Specifically, npm allows fine-grained access tokens that can publish without a second factor. The attack chain would look like this: compromise one developer workstation, scrape all tokens from memory, search GitHub commits for additional tokens, use the collected tokens to publish backdoored versions of any package the tokens have access to. The packages would not need to be popular — the attacker could target internal packages that are only used by one enterprise. The prediction: by Q2 2028, a non-nation-state threat actor will execute a supply chain attack using dead-drop exfiltration of tokens from commit messages, targeting a Fortune 500 company through an internal package registry. The attack will succeed because no team currently monitors commit messages for token exfiltration. Enable your defenses now.