The Mini Shai-Hulud Supply Chain Attack: How Hackers Weaponized SAP's Own Developer Tools
On April 29, 2026, four npm packages at the heart of SAP's Cloud Application Programming (CAP) framework were quietly poisoned. For roughly two to four hours, any developer who ran a standard npm install pulled a credential-stealing payload directly into their workstation or CI/CD pipeline. By the time the attack was neutralized, over a thousand attacker-controlled GitHub repositories had already appeared, each containing exfiltrated data from compromised developer machines.
The campaign, dubbed "Mini Shai-Hulud" by security researchers, was attributed to a group known as TeamPCP. It marked the first time the Shai-Hulud worm family, which originally struck the broader npm ecosystem in September 2025, had reached directly into SAP's developer supply chain.
How the attack worked
The compromised packages were @cap-js/sqlite, @cap-js/postgres, @cap-js/db-service, and mbt. These are core components of the SAP CAP Model and the MTA Build Tool used in SAP BTP deployments, together accounting for roughly 570,000 weekly downloads across the SAP developer community.
The attackers exploited a misconfigured OIDC trusted-publisher rule in SAP's GitHub workflows, extracting short-lived npm publish tokens. They then modified the packages to include a preinstall hook that silently downloaded the Bun JavaScript runtime and executed a heavily obfuscated payload. The malware harvested GitHub tokens, npm credentials, GitHub Actions secrets, and cloud credentials from AWS, Azure, and Google Cloud.
Stolen data was encrypted using AES-256-GCM with RSA-4096 and sent to attacker-controlled GitHub repositories created under victim accounts, each tagged with the description "A Mini Shai-Hulud has Appeared." Those repositories were immediately visible in public GitHub searches. Researchers from Aikido Security, Wiz, Socket, and Onapsis all confirmed the attack independently within hours.
A worm by design
The payload did not stop at credential theft. With any stolen npm token in hand, it could republish itself into every other package the compromised account had access to, turning each victim into a new infection vector. By May 2026, the campaign had expanded to 373 malicious package versions across 169 npm package names, hitting popular ecosystems including @tanstack, @uipath, and @squawk, well beyond the original SAP targets.
The malware also targeted AI coding environments. It committed malicious files to .claude/settings.json, abusing Claude Code's SessionStart hook, and to .vscode/tasks.json, configured to run on folder open. Security researchers at StepSecurity described it as one of the first supply chain attacks to use AI coding agent configurations as a persistence and propagation vector.
One additional detail caught forensic teams off guard: if the system locale was set to Russian, the payload logged "Exiting as russian language detected!" and exited cleanly. That CIS exemption is a known pattern among Eastern European threat actors and pointed investigators toward a Russia or CIS-based operator.
What SAP environments need to do differently
The attack exposed a gap that many security teams had not addressed. The SAP attack surface now extends well beyond ABAP, RFC, and the kernel. CAP, BTP, and the npm packages that build cloud applications are part of the threat surface, and a single malicious preinstall script can convert developer convenience into production credential exposure in minutes.
Immediate response steps for any organization that used the affected packages include rotating all npm tokens, GitHub credentials, GitHub Actions secrets, and cloud credentials across AWS, Azure, and GCP. Teams should audit recent CI/CD pipeline activity for signs of unauthorized publishing, and delete any unexpected GitHub repositories, particularly those with Dune-themed names.
Longer term, securing SAP no longer stops at production systems. It now has to stretch into how applications, extensions, and cloud services are built and deployed. Organizations that want continuous visibility into their SAP BTP environments and supply chain integrity, like those working with tozenLabs, can surface anomalous package installation patterns and unauthorized credential access before the damage propagates. Pinning exact npm versions and enforcing scoped OIDC rules on GitHub workflows are the two highest-leverage configuration changes SAP development teams can make today.