Four SAP npm packages were trojanized on April 29, 2026 with Bun-based credential theft and worm logic. Timeline, code path, and fixes. Read now.
What happened on April 29, 2026
On April 29, 2026, four SAP packages published on npm were trojanized. The compromised releases did not need a separate installer or a novel supply-chain channel. They rode the normal install path: a developer or CI job pulled a package, npm ran lifecycle scripts, and the payload executed with the same privileges as the build or local shell. That is enough to read environment variables, touch credential stores, and talk to the network.
The campaign is often discussed under the Mini Shai-Hulud label because the behavior matches a compact worm pattern: steal secrets, then try to widen reach by abusing the same package ecosystem that delivered the first hit. You do not need a full reverse-engineering dump to reason about impact. If any of the four packages sat in a dependency tree—direct or transitive—assume the host that installed them is untrusted until proven otherwise.
Bun-based credential theft and worm logic
The malware used Bun as its runtime vehicle. Bun is a JavaScript toolkit that can execute scripts quickly with Node-compatible APIs. From an attacker’s view, that is convenient: one runtime can read files, spawn processes, and make HTTP requests without dropping a large custom binary. Lifecycle hooks or post-install entry points can launch Bun and hand off the rest of the job in a few lines of glue code.
Credential theft in this class of malware is usually opportunistic rather than surgical. Expect probes of environment variables, local config files, cloud and CI tokens, npm tokens, and anything else the process can open. Worm logic builds on that haul. If the host holds a publishing credential or can push to a registry-connected repo, the next step is to plant similar code in other packages the compromised identity can update. The loop is simple: install → steal → publish → install elsewhere. That is why a small set of trojanized packages can matter beyond their direct consumers.
Code path to treat as hostile
Think of the attack as a short pipeline, not a single mysterious blob. A clean mental model helps triage without inventing package names or version strings you do not have in hand:
- Package metadata on npm points at a release whose install scripts or nested dependencies run untrusted code.
- That code starts Bun (or falls back to another local JS runtime if present) and loads the payload.
- The payload enumerates secrets, packages them, and exfiltrates over HTTPS or a similar outbound channel.
- If worm logic succeeds, new or updated packages carry the same chain, extending the blast radius to fresh install graphs.
For response work, reconstruct that path from install logs, lockfiles, and process trees. Look for unexpected Bun binaries or scripts spawned during npm install, outbound calls from package scripts, and any publish or token activity after the install window. Treat every secret that could have been readable in that environment as rotated, not merely “checked.”
Fixes and hardening that actually reduce risk
Immediate fixes are operational. Pin and verify versions against known-good lockfiles, remove the four affected packages and any rebuild that may have reintroduced them, wipe or rebuild CI agents and developer machines that ran the bad install, and rotate npm tokens, cloud keys, and other credentials that lived in those environments. Re-publish only from a clean host with a fresh token after you confirm the publish identity was not used for further package updates.
Hardening is structural. Disable or tightly gate lifecycle scripts in CI when your tooling allows it. Prefer lockfile installs with integrity checks. Scope registry tokens to the minimum packages and environments, and separate human publish credentials from automated build credentials. Watch for unexpected package updates in your org’s namespace and for installs that pull Bun or run network-heavy postinstall steps without a documented reason. Mini Shai-Hulud-style incidents succeed when install is trusted by default. Shrink that trust surface, and the same Bun-based credential theft and worm logic has far less room to run.