SAP npm Packages Poisoned: Credential Theft Hits CAP Devs

Four widely used SAP npm packages were quietly backdoored on April 29, 2026, exposing millions of developers to a credential-stealing attack that swept up GitHub tokens, cloud secrets, browser passwords, and AI tool configurations before anyone had a chance to respond.

It took less than four hours. Between 09:55 and 14:00 UTC on April 29, 2026, a threat actor known as TeamPCP published malicious versions of four SAP npm packages that together pull over 2.25 million downloads every month. Any developer who ran npm install during that window didn’t just install a package. They handed over their credentials.

The campaign, which the attacker named “Mini Shai-Hulud” after the sandworms of Frank Herbert’s Dune universe, was uncovered by researchers at Aikido Security, Wiz Research, Socket, SafeDep, and StepSecurity. It targets the SAP Cloud Application Programming (CAP) ecosystem, meaning the victims are predominantly enterprise developers building business-critical cloud applications at some of the world’s largest companies.

The attack didn’t just steal credentials. It was engineered to spread them.

What Happened: A Four-Hour Window

Four packages received malicious updates within a single morning. All were central to SAP’s CAP framework for Node.js. All are now either deprecated or patched with clean replacement versions.

Researchers at Chainguard confirmed the combined download volume, underscoring the scale of potential exposure. The malicious versions were deprecated within roughly four hours, but in CI/CD pipelines and containerized build environments where package versions aren’t always pinned, even a narrow window causes serious damage.

How the Attack Actually Worked

The technique is clean and devastating. Each malicious package version added a single line to its package.json: a preinstall hook pointing to a new file called setup.mjs. That hook fires automatically the moment anyone runs npm install. No user interaction. No confirmation prompt. No warning of any kind.

“The compromised releases added a preinstall script that acts as a runtime bootstrapper, downloading a platform-specific Bun ZIP from GitHub Releases, extracting it, and immediately executing the extracted Bun binary. The implementation also follows HTTP redirects without validating the destination and uses PowerShell with -ExecutionPolicy Bypass on Windows, increasing the risk for affected developer and CI/CD environments.”

Socket Security Research Team — The Hacker News

Choosing the Bun JavaScript runtime was deliberate. Most developer security tooling and CI/CD monitors are tuned to watch Node.js process behavior. Bun sidesteps that coverage entirely. The attacker downloaded Bun v1.3.13 directly from GitHub Releases at install time, then used it to execute the real payload: a file named execution.js.

That file is 11.6 to 11.7 megabytes of heavily obfuscated JavaScript. It’s a full credential-stealing and propagation framework, and its size alone tells you this wasn’t a script thrown together over a weekend.

The Multi-Stage Kill Chain

First, setup.mjs (4,549 bytes, shared identically across all four packages) downloads and extracts the Bun binary. Then Bun runs execution.js, which sweeps the developer’s environment systematically. Data gets encrypted using AES-256-GCM with the key wrapped in RSA-4096 using an embedded attacker public key. Only TeamPCP can decrypt what was stolen. The encrypted packages are pushed to attacker-controlled public GitHub repositories with Dune-themed names like prescient-lasgun-242 and descriptions reading “A Mini Shai-Hulud has Appeared.”

By the end of April 29, researchers had counted over 1,100 exfiltration repositories on GitHub. That number was still climbing when initial reports went out.

What Was Stolen: A Comprehensive Sweep

The payload didn’t target one type of credential. It swept everything a developer might have accessible from their machine or build environment. The scope is striking even by supply chain attack standards.

“The payload is an 11.7 MB credential stealer and propagation framework. It harvests local developer credentials, GitHub and npm tokens, GitHub Actions secrets, and cloud secrets from AWS, Azure, GCP, and Kubernetes. It then exfiltrates encrypted results through public GitHub repositories.”

Raphael Silva, Security Researcher, Aikido Security — Aikido Security Blog

One feature drew particular attention from StepSecurity researchers: the malware injects a .claude/settings.json with a SessionStart hook, and a .vscode/tasks.json configured with runOn: folderOpen. Every time a developer opens the infected repository in VS Code or Claude Code afterward, the payload re-executes. StepSecurity called it one of the first attacks to specifically target AI coding agent configurations as a persistence and propagation vector.

The malware also ships with a Russian locale guardrail. If the system language or date format begins with “ru,” the stealer exits without exfiltrating anything. This type of region exclusion is a consistent marker of threat actors operating within Russian-speaking jurisdictions, and also functions as a practical legal buffer.

How the Attackers Got Publishing Access

The access method differed between the @cap-js packages and mbt, but both paths point to fundamental gaps in how modern open-source projects handle CI/CD trust.

The @cap-js Packages: An OIDC Scope Problem

Researchers at SafeDep traced the root cause to a configuration gap in how the cap-js/cds-dbs repository had set up npm’s OIDC trusted publishing. The team had migrated to OIDC in November 2025, allowing GitHub Actions to request short-lived npm tokens without storing long-lived secrets in the repository. The gap was in the scope of what the configuration trusted.

“npm’s OIDC trusted publisher configuration for @cap-js/sqlite trusted any workflow in cap-js/cds-dbs, not just the canonical release-please.yml on main. A branch push could exchange an OIDC token on behalf of the package if the workflow had id-token: write permission and the environment: npm reference.”

Leon Avalos, SafeDep — cited in The Hacker News

The attacker compromised a GitHub account called RoshniNaveenaS that held write access to the repository. They pushed a modified workflow to a non-main branch via a draft PR titled “feat: ci speedup” from a fork named gruposbftechrecruiter/harkonnen-navigator-149. The PR closed within minutes and the branch was force-pushed, wiping the diff. But the OIDC token exchange had already completed. The resulting CircleCI build logs exposed the npm publish token, GitHub token, OIDC tokens, Docker Hub credentials, and Cloud Foundry credentials before anyone could intervene.

The mbt Package: Token Compromise

For mbt, the path was simpler and murkier. Researchers suspect the cloudmtabot static npm token was compromised through a channel that hasn’t been fully identified yet. The investigation is ongoing. What’s confirmed is that the attacker held valid publish credentials for all four packages and targeted specific version numbers with precision.

Part of a Larger and Accelerating Pattern

Mini Shai-Hulud is TeamPCP’s fourth confirmed operation in roughly five weeks. The pace is notable, and each campaign has added new capabilities.

Attribution across all four campaigns was confirmed by Wiz Research through a shared RSA public key alongside overlapping encoding routines and region guardrails. The actor is also tracked under the aliases DeadCatx3, PCPcat, and ShellForce, per SecurityWeek’s tracking of the group.

“A new supply chain operation from TeamPCP calling itself ‘Mini Shai Hulud’ compromised SAP-related npm packages by injecting malicious preinstall scripts that execute during dependency installation. TeamPCP is very likely responsible for this campaign, based on a shared RSA public key and overlaps in encoding routines and region guardrails.”

Wiz Research Team, Wiz (Google-owned) — Wiz Research Blog

The broader trend adds weight. According to PkgPulse’s trend analysis, npm supply chain attacks roughly tripled between 2022 and 2025. TeamPCP didn’t cause that trend, but they’re currently its sharpest expression. It’s also worth noting that SAP’s own April 2026 security patch cycle released 19 new security notes including a CVSS 9.9-rated SQL injection in SAP BPC and BW, per SAP Insider. Enterprise SAP environments were already under pressure from the vendor side before this npm campaign landed.

What Affected Teams Should Do Right Now

Remediation isn’t just about updating package versions. If the malicious version ran in your environment, you have a credential exposure problem, not a package problem. The Sophos CTU Research Team was direct: investigate whether compromised versions were installed, review all GitHub, npm, and cloud activity tied to potentially exposed credentials, and rotate anything that may have been accessible.

• Check your package-lock.json and build logs for the malicious version numbers: @cap-js/sqlite v2.2.2, @cap-js/postgres v2.2.2, @cap-js/db-service v2.10.1, and mbt v1.2.48.
• Compare installed tarballs against the SHA256 hashes listed in the infobox above. A match confirms the payload executed on that machine.
• Rotate all GitHub tokens, npm tokens, and cloud provider credentials accessible from any affected build environment. Don’t wait to confirm; rotate first, investigate second.
• Search your GitHub organization’s audit log for the commit message keyword OhNoWhatsGoingOnWithGitHub. This is the propagation dead-drop marker the malware uses for token exchange between infected systems.
• Check for injected .claude/settings.json and .vscode/tasks.json files in repositories recently touched from affected machines. These are the persistence hooks.
• Review browser credential stores on developer machines that ran the malicious install, specifically Chrome, Safari, Edge, Brave, and Chromium password managers.
• Update all affected packages to their clean versions and enforce explicit version pinning across your dependency tree going forward.

For teams working on CI/CD pipeline security hardening, this incident is a live case study in why preinstall script auditing needs to be part of every build pipeline by default. The npm ecosystem doesn’t sandbox lifecycle scripts, doesn’t prompt for confirmation, and grants full system access by default. That architecture hasn’t changed in years.

Frequently Asked Questions

The Bigger Picture: Trust Is the Attack Surface

The Mini Shai-Hulud attack is a study in how trust chains collapse at scale. SAP developers trusted @cap-js/sqlite because it had millions of downloads and came from a recognized source. npm users trusted the preinstall hook because it’s a standard part of the package specification. CI/CD pipelines trusted the OIDC token exchange because it was explicitly configured to be trusted. At every step, a legitimate mechanism became an attack vector.

The credential theft is serious enough on its own. But the propagation design is what should concern security teams most. Stolen GitHub tokens don’t just expose the original victim. They expose every repository that token can reach, every pipeline it can trigger, and every secret those pipelines can access. The attacker built a cascading compromise engine, not a one-shot stealer.

For the broader npm ecosystem, supply chain security has moved from secondary concern to first-tier priority. Postinstall and preinstall scripts are the single most-exploited vector in npm compromises. That’s been documented since the 2018 event-stream incident. The npm runtime still doesn’t sandbox them, still doesn’t prompt for confirmation, and still grants full system access by default. What has changed is the sophistication of the actors who know exactly how to exploit it.

TeamPCP has now run four confirmed operations in five weeks, and each campaign adds new capabilities. Browser credential theft wasn’t in their prior toolkit. Targeting AI coding tool configurations is genuinely novel territory. For organizations running SAP enterprise environments, the immediate priority is investigation and credential rotation. For everyone else, this is a concrete reminder that your software supply chain security is only as strong as the weakest OIDC configuration in your entire dependency graph.