SAP-Focused npm Supply Chain Attack Compromises Packages to Steal Credentials

Key Takeaways

• A supply‑chain attack dubbed “mini Shai‑Hulud” compromised four SAP‑related npm packages (mbt, @cap-js/db-service, @cap-js/postgres, @cap-js/sqlite) by injecting a pre‑install script that downloads and runs a malicious Bun binary.
• The malware harvests developer credentials, GitHub/npm tokens, GitHub Actions secrets, and cloud service secrets (AWS, Azure, GCP, Kubernetes), encrypts the data with AES‑256‑GCM protected by an RSA‑4096 key, and exfiltrates it to attacker‑controlled GitHub repositories.
• Persistence is achieved by abusing AI‑coding‑agent configuration files (.claude/settings.json and .vscode/tasks.json) so that opening an infected repository in VS Code or Claude Code triggers execution.
• The attack leverages a misconfiguration in npm’s OIDC trusted‑publisher setup: any workflow in the cap-js/cds-dbs repository with id-token: write and environment: npm could obtain a short‑lived npm token, allowing the attacker to publish poisoned package versions without provenance.
• Maintainers have released clean versions that supersede the malicious releases; users should upgrade immediately and audit any CI/CD workflows that may have been tampered with.

Overview of the Compromised Packages
On April 29, 2026, between 09:55 UTC and 12:14 UTC, four npm packages widely used in SAP’s JavaScript and cloud‑application development ecosystem were published with malicious code. The affected versions were [email protected], @cap-js/[email protected], @cap-js/[email protected], and @cap-js/[email protected]. Researchers from Aikido Security, SafeDep, Socket, StepSecurity, and Google‑owned Wiz identified that these releases introduced a new preinstall hook in each package’s package.json. The hook executes a file named setup.mjs, which acts as a loader for the Bun JavaScript runtime, ultimately running an additional script (execution.js) that carries out credential theft and self‑propagation. The timing and uniform nature of the modifications pointed to a coordinated supply‑chain campaign rather than isolated accidents.

How the Malicious Pre‑install Script Works
The injected preinstall script downloads a platform‑specific Bun ZIP archive from a GitHub Releases endpoint, extracts it, and immediately runs the Bun binary. Notably, the script follows HTTP redirects without validating the final destination, which could allow an attacker to serve the payload from an arbitrary host after a redirect. On Windows systems, the script invokes PowerShell with the -ExecutionPolicy Bypass flag, further lowering defenses and facilitating execution in developer machines and CI/CD runners. By leveraging Bun—a relatively new JavaScript runtime—the attackers obscure their activity behind a tool that many security scanners may not yet treat as suspicious, increasing the likelihood of successful infiltration.

Data Harvesting and Exfiltration Mechanism
Once executed, the malware (execution.js) surveys the local environment for a wide range of secrets: developer usernames and passwords, GitHub personal access tokens, npm authentication tokens, GitHub Actions encrypted secrets, and cloud credentials for AWS, Azure, GCP, and Kubernetes. The collected data is encrypted using AES‑256‑GCM, with the symmetric key itself wrapped by an RSA‑4096 public key embedded in the payload. This hybrid encryption ensures that only the threat actor, possessing the corresponding private RSA key, can decrypt the stolen information. The ciphertext is then pushed to newly created public GitHub repositories under the victim’s own account; each repository bears the description “A Mini Shai‑Hulud has Appeared.” As of the latest reports, more than 1,100 such repositories have been created, indicating a broad impact across the developer community.

Persistence and Propagation Techniques
Beyond data theft, the payload is designed to self‑propagate. Using the stolen GitHub and npm tokens, the malware creates or modifies GitHub Actions workflows within the victim’s repositories. These workflows are configured to (1) exfiltrate repository secrets and (2) publish poisoned versions of the compromised npm packages back to the registry, thereby expanding the attack surface. To guarantee execution on developer workstations, the malware writes two configuration files: .claude/settings.json, which abuses Claude Code’s SessionStart hook, and .vscode/tasks.json with a "runOn": "folderOpen" setting. Consequently, any attempt to open an infected repository in Microsoft Visual Studio Code or Claude Code automatically triggers the malicious script, establishing a stealthy persistence mechanism that survives repository clones and local edits.

Novel Targeting of AI Coding Agent Configurations
Security analysts from StepSecurity highlighted that abusing .claude/settings.json represents one of the first observed supply‑chain attacks that specifically target AI‑coding‑agent configuration files as a vector for persistence and propagation. By hooking into Claude Code’s SessionStart event, the attackers ensure that their code runs whenever a developer initiates a Claude‑assisted coding session, irrespective of traditional IDE defenses. This tactic underscores a shift in adversary focus toward emerging developer tooling ecosystems, where security tooling may lag behind feature adoption, providing attackers with fresh footholds.

Root Cause: OIDC Trusted‑Publisher Misconfiguration
Investigations traced the initial compromise to the cap-js/cds-dbs repository, which maintains the @cap-js npm packages. The repository had adopted npm’s OIDC‑based trusted publishing in November 2025, allowing GitHub Actions workflows to request short‑lived npm tokens without storing long‑lived secrets. However, the OIDC trust configuration was overly permissive: it granted any workflow in the repository—not just the canonical release-please.yml on the main branch—the ability to exchange an OIDC token for npm publishing, provided the workflow possessed id-token: write permission and referenced the npm environment.

The attacker first gained control of the maintainer account RoshniNaveenaS (likely via credential theft or phishing) for the three @cap-js packages. They then pushed a malicious commit to a non‑main branch, triggering a workflow that satisfied the lax OIDC conditions. The workflow exchanged an OIDC token for an npm token, which was printed in the CI logs and subsequently used to publish the tainted package versions. For the mbt package, analysts suspect a separate vector: the theft of a static npm token belonging to the automated user cloudmtabot, though the exact acquisition method remains under investigation.

Response and Remediation Steps
Upon discovering the intrusion, the package maintainers promptly released clean versions that supersede the malicious releases. Users are advised to upgrade to the latest safe iterations of mbt, @cap-js/db-service, @cap-js/postgres, and @cap-js/sqlite immediately. Organizations should audit their CI/CD pipelines for any unauthorized workflow modifications, especially those with id-token: write and npm environment settings, and enforce the principle of least privilege when configuring npm’s OIDC trusted publishers—limiting token issuance to specific workflows and branches. Additionally, developers should scan their local machines for the presence of the malicious Bun binary, review recent GitHub Actions logs for unexpected token usage, and rotate any potentially exposed credentials, including GitHub/npm tokens and cloud service keys.

Broader Implications for Supply‑Chain Security
The “mini Shai‑Hulud” campaign illustrates several evolving threats in the software supply chain. First, attackers are increasingly abusing legitimate automation mechanisms—such as OIDC‑based token exchanges—to bypass traditional secret‑management safeguards. Second, the utilization of emerging runtimes like Bun and the manipulation of AI‑agent configuration files show that adversaries are quick to adopt new developer tools before protective measures mature. Third, the hybrid encryption of exfiltrated data raises the bar for defenders seeking to monitor outbound traffic, as the ciphertext appears benign without the private RSA key. Consequently, security teams must adopt a defense‑in‑depth strategy: enforce strict OIDC scoping, maintain immutable provenance for published artifacts, monitor for anomalous GitHub repository creation, and employ runtime behavior analysis that can detect unauthorized execution of bundlers or scripts triggered by IDE hooks. By addressing these gaps, the community can reduce the likelihood that future supply‑chain attacks achieve the same level of reach and impact.