What happened#
Snyk reports that attackers published malicious versions of four npm packages in the SAP Cloud Application Programming Model ecosystem on April 29, 2026. The affected packages include SAP CAP database service packages under @cap-js and the Cloud MTA Build Tool package used to build deployment archives for SAP cloud applications.
The compromised releases shipped a hook that downloaded the Bun JavaScript runtime from GitHub Releases. Bun was then used to run an obfuscated credential stealer of about 11.6 MB. The payload identified itself with the hardcoded phrase: “A Mini Shai-Hulud has Appeared.”
That phrase was not just decoration. Snyk says compromised developer machines created public GitHub dead-drop repositories under their own accounts, and those repositories were visible through GitHub search results in real time. The campaign reused the Shai-Hulud name and tagging pattern seen in earlier npm supply-chain attacks.
Snyk published advisories for the compromised releases, including advisories for @cap-js/db-service, @cap-js/sqlite, and @cap-js/postgres. The source material also states that four malicious versions were observed in the wild at publication time, and that the releases were published in a tight UTC window on April 29.
The important limit is this: Snyk’s public reporting says only the four originally compromised packages had been observed carrying the malicious payload at publication time. That does not make the incident harmless. It means the observed spread was narrower than prior Shai-Hulud waves when the article was published.
Why it matters#
This incident hit developer infrastructure, not an end-user application. That is the point.
The affected packages sit in the SAP application development toolchain. Developers and CI systems may install them as part of normal build work. If a malicious release runs during install or build steps, the attacker is operating close to credentials, package tokens, repository access, and deployment paths.
The payload behavior described by Snyk and other researchers is credential-focused. It uses Bun to execute a large obfuscated stealer. StepSecurity’s deobfuscation, as cited by Snyk, found functional npm self-propagation code. The payload harvests npm tokens, validates them against npm registry token endpoints, checks write scope, enumerates accessible packages, patches itself into a tarball copy, and publishes directly to the npm registry without invoking the npm CLI.
That last part is what raises the risk profile. Even if no fifth infected package had been observed at publication time, worm-capable code was reportedly present and functional. The gap between “capable” and “observed spreading” matters, but defenders cannot treat the capability as hypothetical once deobfuscated code shows the path.
The campaign also shows why package manager security cannot be reduced to dependency pinning alone. The initial compromise appears tied to a release workflow. According to SAP’s public statement quoted by Snyk, an unauthorized actor pushed malicious commits that hijacked a release workflow and triggered unauthorized npm publications. SAP said the attacker could publish compromised packages because the workflow had publish permissions without a manual approval gate.
That is a release governance failure. It turns CI/CD into a signing and publishing machine for the attacker.
What is different from earlier Shai-Hulud waves#
The Shai-Hulud name has already been attached to major npm supply-chain incidents. Snyk notes earlier waves in September 2025 and November 2025, with the later wave affecting hundreds of packages, including packages associated with well-known companies. Kaspersky also published independent technical analysis of those prior waves.
This April 2026 case borrows the same naming convention and dead-drop style, but the public evidence described by Snyk points to a smaller observed blast radius at publication time.
The difference is not that this campaign is benign. It is that it appears narrower so far. Snyk’s wording is careful: only four originally compromised packages had been observed in the wild with the payload, while StepSecurity’s static analysis found real self-publishing capability.
That distinction matters for response. Teams should not claim a massive ecosystem-wide spread unless evidence appears. They also should not ignore the incident because the observed package count was small. A worm-capable npm stealer inside enterprise development tooling is enough to justify immediate checks.
Response and remediation status#
Snyk says SAP responded by publishing clean post-incident versions for at least some affected packages using GitHub Actions OIDC trusted publishing. The source material states that SAP gated npm publication behind a manual approval environment after the incident.
Some malicious releases were unpublished shortly after detection. Other malicious versions carried npm deprecation warnings such as “SECURITY: This version contains malicious code. Do not use.” and “DO NOT USE. This version contains unknown content.” At the time described in the source material, at least one package did not yet have a remediated version published, meaning a bare install could still resolve to a malicious tarball.
No CVE had been assigned for any of the four packages at publication time, according to Snyk. That is common in npm supply-chain incidents and should not delay action. The authoritative signals here are the vendor advisories, npm package metadata, GitHub disclosure issues, and direct dependency inventory.
What teams should check now#
Start with package exposure. Look for the affected SAP CAP and Cloud MTA Build Tool packages in application repositories, lockfiles, local developer environments, and CI caches. Do not only search production manifests. Developer tools often live in templates, build scripts, internal scaffolds, and old branches.
Check whether any install or build ran during the compromise window on April 29, 2026. Prioritize CI jobs and developer machines that had npm publish rights, GitHub write access, SAP deployment credentials, cloud credentials, or secrets in environment variables.
Practical checks:
- Review
package-lock.json,pnpm-lock.yaml,yarn.lock, and CI logs for the compromised package versions named in vendor advisories. - Remove deprecated or malicious versions and upgrade to clean releases where available.
- Rotate npm tokens that were present on systems that may have installed the affected packages.
- Review npm account activity for unexpected package publishes, token use, or changes to package metadata.
- Inspect GitHub accounts for unusual repositories matching dead-drop behavior or Shai-Hulud-related naming.
- Review CI workflows that can publish packages without manual approval.
- Prefer npm trusted publishing/OIDC where supported, and require environment review for release jobs.
The workflow lesson is direct. A package token with broad write access and an automated publish path is a high-value target. If a CI job can publish without human approval, an attacker who reaches that workflow may not need to compromise a maintainer’s local machine.
What not to overclaim#
The public reporting does not support saying that the April 2026 campaign spread across hundreds of packages. It also does not support saying that every SAP CAP user was compromised. The observed malicious package set was limited at publication time.
It does support a sharper claim: malicious versions were published into SAP development ecosystem packages; they executed a Bun-based credential stealer; public dead-drop repositories appeared from compromised developer accounts; and deobfuscated code contained functional npm self-propagation logic.
That is enough. The incident is a reminder that supply-chain defense lives at the seam between dependencies, identities, and release automation. If the publishing path is too trusted, the package registry becomes the attacker’s distribution channel.