SAP @cap-js and mbt npm packages hijacked (Mini Shai-Hulud): installing them could steal login keys and spread the worm

Who is affected

This is not a coding bug. Official SAP packages were swapped for malicious versions (CWE-506, Embedded Malicious Code). Two related but separate compromises happened on the same day: the three @cap-js packages (GHSA-pvw4-cvr4-97p8 / CVE-2026-46421), and mbt (tracked separately as MAL-2026-3179 and not part of that CVE).

For scale: Socket puts weekly downloads at about 260k for db-service, 250k for sqlite, 52k for mbt and 10k for postgres. SafeDep estimates about 1.2 million installs per month across the four packages.

How it works

How the attackers got publishing rights.

• @cap-js: In PR #1592, SAP says an unauthorized actor pushed malicious commits that hijacked the release workflow and triggered unauthorized npm publications, and that there was no manual approval before npm publishing. SAP does not say whether that publishing used trusted publishing (OIDC) or an npm token, and researchers give different accounts:
  • StepSecurity and SafeDep say the attacker controlled an SAP developer’s GitHub account, changed the release workflow so it would run from a non-main branch, used the CI job’s OIDC identity to obtain npm publish credentials through trusted publishing, printed them to the build log in encoded form, and published with them.
  • Snyk, citing npm registry data, says all four malicious versions (including the three @cap-js ones) were published from the cloudmtabot account; OSV’s MAL-2026-3178 and MAL-2026-3179 also say they were published by “cloudmtabot@gmail.com”.
  • SAP has not said publicly which is correct, and this page cannot settle it.
• mbt: According to StepSecurity, 1.2.48 was published with a long-lived npm token for the cloudmtabot account; mbt never used trusted publishing. How that token was stolen is unconfirmed. BleepingComputer cites security engineer Adnan Khan as saying an npm token in SAP’s npm publishing process may have been exposed through a misconfigured CircleCI job, without naming the package; no source confirms that this was the mbt token.

The configuration gap. npm trusted publishing ties publishing rights to an organization, a repository and an exact workflow filename. A GitHub deployment environment (which can require approval) is optional. SafeDep and StepSecurity say the trust here was not limited to a protected branch or an approval-gated environment, so a workflow run from the attacker’s own branch could still get publish credentials. SAP’s exact configuration could not be confirmed for this page. If the cloudmtabot publishing that Snyk and OSV describe is what actually happened, this gap was not the direct cause, although SAP did add a manual approval step before publishing afterwards.

The flawed approach (conceptual illustration, not SAP’s actual configuration):

# npm trusts: this repo + release.yml
# No environment binding → release.yml on any branch can get publish credentials
jobs:
  publish:
    permissions:
      id-token: write

The fixed approach:

# npm trusts: this repo + release.yml + environment "npm-release"
# Environment rules live in repo settings (editing the workflow can't change them):
#   only the protected main branch, maintainer approval required
jobs:
  publish:
    environment: npm-release
    permissions:
      id-token: write

The key point: writing “only run on main” inside the workflow file isn’t enough, because the attacker can edit that file. The restriction has to live somewhere the attacker can’t change, such as the environment’s protection rules.

What the malicious code did. The official advisory says only that it harvested credentials and “attempted self-propagation”; the details below come from researchers such as StepSecurity, SafeDep and Snyk.

1. The malicious versions added setup.mjs and execution.js to otherwise normal package contents and changed package.json. According to SafeDep, the three malicious @cap-js versions had no npm provenance attestation, while the previous legitimate releases did; no mbt version on npm registry has ever carried provenance, so this applies to @cap-js only.
2. setup.mjs ran as a preinstall script, so installing was enough; nothing had to be imported. It downloaded the legitimate Bun runtime and used it to run an obfuscated payload of about 11 MB (OSV says 11.1 MB, StepSecurity says 11.6 MB).
3. It stole npm and GitHub tokens, SSH keys, AWS/Azure/GCP credentials and secrets-manager access, Kubernetes configs and CI/CD secrets, plus AI tool configs and crypto wallets. On GitHub Actions it read secrets directly from the runner process’s memory, getting around log masking.
4. It encrypted the data and committed it to new public repositories in the victim’s own account, described as “A Mini Shai-Hulud has Appeared”. SafeDep also describes an HTTPS command-and-control endpoint, so the reports differ in detail.
5. Self-propagation: according to StepSecurity’s deobfuscation, it uses stolen npm tokens to publish infected versions of other packages the victim can publish, and uses a stolen GitHub token with write access to commit persistence files into repositories (injecting a workflow also needs a token with workflow scope). When Snyk published, it had seen only the original four packages compromised.

AI coding agents turned into a backdoor. According to StepSecurity and SafeDep, when the worm got a GitHub token with the right permissions it committed .claude/settings.json (with a SessionStart hook) and .vscode/tasks.json (set to run when a folder opens), so the payload ran again whenever a developer opened the project or started an AI coding-agent session. The commits appeared under the author “claude” with unverified signatures, looking like routine AI-assistant changes. StepSecurity calls this one of the first supply-chain attacks to abuse AI-agent configuration this way. The attackers also pushed a branch named to imitate Dependabot, carrying a workflow meant to dump repository secrets. StepSecurity and Socket report a kill switch that stops the malware on Russian-locale systems.

Timeline

Further reading

• Identifier correction. The incident record this page started from said there was no CVE, but GitHub has assigned CVE-2026-46421 to GHSA-pvw4-cvr4-97p8. It is still not in CISA KEV. The CVE covers only the three @cap-js packages; mbt was a separate compromise carried out a different way.
• Scoring. The only score is GitHub’s (CNA) CVSS 4.0 9.3 Critical. NVD has not scored it (Deferred), and no CVSS 3.x score was found. CISA’s SSVC field in the CVE record says Exploitation “none”; that is a data field, not a statement that no attack happened. Researchers watched this malware spread in the wild.
• Date basis. This page gives 2026-04-29 as the disclosure date: the day the first malicious version (mbt 1.2.48, 09:55 UTC) appeared on npm. For supply-chain compromises, this site always uses the date the malicious versions appeared. The maintainers’ advisory (05-14) and the CVE (07-15) came later.
• Where sources disagree. On how the @cap-js versions were published, SAP says only that the hijacked workflow triggered unauthorized npm publications; StepSecurity and SafeDep say credentials were obtained through trusted publishing (OIDC), while Snyk and OSV say the cloudmtabot account published them. On the fixed @cap-js/sqlite version, the maintainers’ advisory and the CVE description say 2.4.0 or later, while the structured data in GitHub’s global database and OSV says 2.3.0, a version that never appeared on npm. The payload size is given as both 11.1 MB and 11.6 MB. For the exfiltration channel, StepSecurity names GitHub’s API while SafeDep describes an HTTPS command-and-control endpoint.
• Campaign background. The first Shai-Hulud wave (September 2025) was a self-copying npm worm that ran from install scripts. The second (November 2025, Shai-Hulud 2.0) moved to preinstall with a Bun loader, and Unit 42 counted more than 25,000 malicious repositories. StepSecurity calls this incident the third wave.
• Attribution is a researcher assessment only. Socket links it with medium confidence to TeamPCP (shared cipher, Russian-locale kill switch, GitHub abused for command and control). StepSecurity points to Eastern European or Russian operators. There is no official attribution.
• File hashes and further network indicators are in StepSecurity’s report; the official advisories don’t publish them, so this page doesn’t reproduce them.
• Related weakness type: CWE-506 (Embedded Malicious Code).