SAP developers face npm supply shock

Malicious code inserted into four SAP-related npm packages exposed developer workstations and automated build systems to credential theft, marking a sharp escalation in attacks against open-source software supply chains used by enterprise technology teams.

The compromised packages were published on April 29, 2026, and affected components tied to SAP’s Cloud Application Programming Model and Multi-Target Application build workflows. The malicious versions identified were @cap-js/sqlite 2.2.2, @cap-js/postgres 2.2.2, @cap-js/db-service 2.10.1 and mbt 1.2.48. Each carried installation-time code that could run before developers had a practical chance to inspect the package contents.

The attack has been labelled “Mini Shai-Hulud” by security researchers because of overlaps with earlier worm-style campaigns targeting developer ecosystems. Its purpose was not limited to stealing a single credential set. The payload was built to harvest GitHub tokens, npm tokens, GitHub Actions secrets, local developer credentials and cloud keys associated with AWS, Azure, Google Cloud and Kubernetes environments.

The method relied on a package. json preinstall hook that launched a file called setup. mjs. That loader downloaded the Bun JavaScript runtime, a legitimate alternative to Node. js, and used it to execute a heavily obfuscated payload named execution. js. The payload was about 11.6 MB, unusually large for this type of implant, and its use of Bun appears designed to evade security monitoring focused on conventional Node. js execution paths.

The timing of the malicious publications was narrow but consequential. The suspect versions were pushed between 09:55 UTC and 12:14 UTC on April 29, leaving a window in which automated builds, fresh installations and dependency refreshes could have pulled the poisoned packages. In enterprise environments, such packages may be installed by CI/CD pipelines without direct human intervention, increasing the risk that secrets held in build runners were exposed.

The attack targeted a sensitive part of the SAP developer ecosystem. CAP is widely used for building cloud-native business applications on SAP Business Technology Platform, while mbt is used to build and package multi-target applications for deployment. That made the compromise relevant not only to individual developers but also to corporate software factories handling production credentials and deployment automation.

The malware encrypted stolen information before exfiltration, using AES-256-GCM and RSA-4096 techniques that restricted decryption to the attackers. Stolen data was routed through public GitHub repositories created under victim accounts, with repository descriptions linked to the Mini Shai-Hulud campaign. The design turned trusted developer accounts into part of the attacker’s infrastructure.

The payload also contained propagation features. With access to GitHub and npm tokens, it could attempt to add malicious GitHub Actions workflows to repositories and publish further poisoned package versions. That behaviour shows how modern supply chain attacks increasingly seek to move laterally through code-hosting systems, package registries and automation platforms rather than relying on a single infected machine.

A notable element was the abuse of developer tooling configurations, including settings tied to Visual Studio Code and AI coding-agent workflows. The malware could place files that triggered execution when a repository was opened in certain development environments. That technique points to a shift in attacker attention towards AI-assisted coding tools and editor automation, both of which are becoming embedded in software teams.

SAP responded by addressing the incident through a security note and by replacing malicious versions with safe releases. Developers and administrators using the affected packages have been urged to remove the compromised versions, update to clean releases, audit dependency lockfiles and rotate exposed credentials. The most urgent checks involve npm tokens, GitHub personal access tokens, cloud service keys, CI/CD secrets and repository-level automation permissions.

The compromise also highlights a broader weakness in trusted publishing and package release pipelines. Security analysis indicates the attackers abused gaps in npm’s OIDC-based trusted publishing flow for the affected @cap-js packages, while the mbt compromise may have involved a static npm token. The distinction matters because both routes point to the same operational risk: attackers are targeting release infrastructure as much as source code.

The wider npm ecosystem remains a favoured target because it combines vast scale with high dependency reuse. Academic work on npm vulnerability propagation has shown that dependency networks can spread risk across large numbers of downstream packages, while newer research on malicious package detection has found that attackers can evade tools when behaviour is obfuscated, installation-triggered or blended with legitimate package activity.

The SAP npm incident adds to a pattern of attacks against developer trust chains, where malware is delivered through packages that appear legitimate and are installed as part of routine work. The affected versions were available only for a limited period, but the potential impact extends to any environment that installed them during that window, especially where secrets were accessible to local machines or automated runners.