SAP-Related npm Packages Compromised in Credential-Stealing Supply Chain Attack

Cybersecurity researchers are sounding the alarm about a new supply chain attack campaign targeting SAP-related npm Packages with credential-stealing malware.

According to reports from Aikido Security, SafeDep, Socket, StepSecurity, and Google-owned Wiz, the campaign – calling itself the mini Shai-Hulud – has affected the following packages associated with SAP's JavaScript and cloud application development ecosystem -

• [email protected]
• @cap-js/[email protected]
• @cap-js/[email protected]
• @cap-js/[email protected]

"The affected versions introduced new installation-time behavior that was not previously part of these packages' expected functionality," Socket said. "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."

Wiz noted that the malicious packages match several features present in previous TeamPCP operations, indicating that the same threat actor is likely behind the latest campaign.

The suspicious versions were published on April 29, 2026, between 09:55 UTC and 12:14 UTC. The poisoned packages introduce a new package.json preinstall hook that runs a file named "setup.mjs," which acts as a loader for the Bun JavaScript runtime to execute the credential stealer and propagation framework ("execution.js").

According to Aikido, the malware is designed to harvest local developer credentials, GitHub and npm tokens, GitHub Actions secrets, and cloud secrets from AWS, Azure, GCP, and Kubernetes. The stolen data is encrypted and exfiltrated to public GitHub repositories created on the victim's own account with the description "A Mini Shai-Hulud has Appeared." As of writing, there are more than 1,100 repositories with descriptions.

In addition, the 11.6 MB payload comes with capabilities to self-propagate through developer and release workflows, specifically using the GitHub and npm tokens to inject a malicious GitHub Actions workflow into the victim's repositories to steal repository secrets and publish poisoned versions of the npm packages to the registry.

However, the latest incident bears significant differences from prior Shai-Hulud waves -

• All exfiltrated data is encrypted with AES-256-GCM and encapsulates the key using RSA-4096 with a public key embedded in the payload, effectively making it decipherable only to the attacker.
• It exists on Russian-locale systems.
• The payload commits itself into every accessible GitHub repository by injecting a ".claude/settings.json" file that abuses Claude Code's SessionStart hook and a ".vscode/tasks.json" file with "runOn": "folderOpen" setting so that any attempt to open the infected repository in Microsoft Visual Studio Code (VS Code) or Claude Code causes the malware to be executed.

"This is one of the first supply chain attacks to target AI coding agent configurations as a persistence and propagation vector," StepSecurity said.

Further analysis into the root cause has revealed that the attackers compromised RoshniNaveenaS's account for the three "@cap-js" packages, followed by pushing a modified workflow to a non-main branch and using the extracted npm OIDC token to publish the malicious packages without provenance. As for mbt, it's suspected to involve the compromise of the "cloudmtabot" static npm token through an as-yet-undetermined channel.

"The cds-dbs team migrated to npm OIDC trusted publishing in November 2025," SafeDep said. "Under this setup, GitHub Actions can request a short-lived npm token without storing any long-lived secrets in the repository. The attacker reproduced this exchange manually in a CI step and printed the resulting token."

"The critical configuration gap: 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."

In response to the incident, the maintainers of the packages have released new safe versions that supersede the compromised releases.