The Shai-Hulud Worm Returns: New npm Supply Chain Attack Compromises SAP Packages

The Shai-Hulud worm has resurfaced, with a new variant dubbed “Mini Shai-Hulud” targeting widely used SAP npm packages through malicious preinstall scripts that execute during npm install before dependency validation and most security tooling runs. This activity has been linked to patterns associated with TeamPCP, though attribution remains inconclusive.

First disclosed on April 29, 2026 by Aikido security researchers, this variant represents the latest evolution in the Shai-Hulud campaign series observed since September 2025 and introduces three key changes:

• Persistence through AI coding agent configurations, including Claude Code and VS Code.
• Encrypted credential exfiltration using attacker-controlled keys.
• Execution controls that disable the payload on Russian-locale systems.
  

These changes extend execution beyond dependency installation into repository interaction and developer tooling, allowing propagation to continue after the initial install event.

What Is the Shai-Hulud Worm?

Shai-Hulud is a self-propagating npm worm, first observed in September 2025, that uses package lifecycle scripts to execute during installation, harvest credentials and republish infected package versions using those credentials.

The name “Shai-Hulud” references the sandworms from Dune, reflecting the attack’s ability to move through the ecosystem and expand as it consumes new environments. The worm operates by injecting malicious preinstall or postinstall scripts into a package’s package.json, ensuring execution whenever a developer or CI runner installs the dependency.

Once executed, the payload extracts credentials directly from the runtime environment, including npm tokens, GitHub tokens and CI/CD secrets. These credentials are then reused to publish new malicious package versions or modify repositories tied to the compromised account.

Unlike typical supply chain attacks that rely on a single compromised package, Shai-Hulud is wormable. The compromise doesn’t stop at the initial package. A single exposed credential can trigger automated republishing across multiple packages and repositories, turning each downstream install into a new propagation point.

Concerned about TeamPCP? Confirm your exposure in 30 minutes.

Affected SAP nmp Packages

Core packages in SAP’s Cloud Application Programming (CAP) Model have been confirmed to be compromised.

These packages sit directly in SAP CAP development and build workflows, meaning installation occurs on developer machines and CI runners where npm tokens, GitHub tokens and CI/CD secrets are already present.

Exposure extends beyond direct installs. These packages are frequently pulled in as transitive dependencies, allowing the malicious preinstall hook to execute across downstream services and pipelines that do not explicitly depend on them.

How the Shai-Hulud Worm Executes: The Preinstall Script Attack Chain

The malware executes through a malicious preinstall lifecycle hook in package.json, which Node.js runs automatically during npm install, before lockfile validation, tests or most security tooling can inspect the package.

"scripts": {  
	"preinstall": "node setup.mjs"
}

Stage 1: Loader Execution

The preinstall hook runs setup.mjs, which downloads the Bun runtime v1.3.13 and uses it to execute an obfuscated payload execution.js of approximately 11 MB. This shifts execution outside the standard Node.js runtime and into a downloaded binary.

Stage 2: Environment-Aware Payload

The payload checks whether it is running inside a CI environment:

if (process.env.GITHUB_ACTIONS) {
	// CI-targeted credential harvesting
}

In CI runners, the payload targets credentials available in the execution environment, including npm tokens, GitHub tokens and CI/CD secrets.

Stage 3: Credential Collection and Exfiltration

The payload extracts credentials directly from the environment, including:

• npm tokens from .npmrc
• GitHub tokens and CLI auth output.
• CI/CD environment variables.
• Cloud credentials: AWS, Azure, GCP.
• Kubernetes service account tokens.

Collected data is compressed and encrypted (AES-256-GCM) and exfiltrated through GitHub repositories using repository creation and commit operations.

Stage 4: Token Reuse and Propagation Setup

The malware searches GitHub commits for the propagation marker:

OhNoWhatsGoingOnWithGitHub:<base64>

Matching commit messages are decoded into GitHub tokens and validated for repository access. These tokens are then used to publish malicious package versions and modify repositories, enabling propagation across the npm ecosystem.

How the Worm Spreads Across Repositories and Packages

Once the malware harvests an npm or GitHub token from a compromised CI run or developer environment, it uses that token to publish infected package versions and push malicious commits under the same maintainer or organization, creating a cascading propagation chain across repositories and the npm ecosystem.

The propagation follows a repeatable sequence:

1. Execution during install: A developer machine or CI runner executes npm install, triggering the preinstall hook and running the payload.
2. Credential exfiltration: The payload extracts npm tokens, GitHub tokens, and CI/CD secrets and exfiltrates them to attacker-controlled GitHub repositories.
3. Token validation: Stolen GitHub tokens are checked for repository access and permissions to push commits or publish packages.
4. Package-level propagation: Using npm tokens, the malware publishes trojanized versions of additional packages controlled by the compromised maintainer or organization.
5. Repository-level propagation: Using GitHub tokens, the malware pushes commits that introduce payload files, such as setup.mjs and execution.js or modify workflows to ensure execution in downstream environments.
6. Commit-based token reuse: The malware searches GitHub commits for the propagation marker:

OhNoWhatsGoingOnWithGitHub:<base64>

Matching commit messages are decoded into GitHub tokens and reused to access additional repositories.

7. Recursive spread: Each newly compromised package or repository becomes a new execution point. When downstream consumers install these packages, the same credential harvesting and republishing process repeats.
   

This propagation model allows a single compromised token to expand into multiple infected packages and repositories, enabling spread across hundreds or thousands of downstream environments as dependencies are installed.

What Makes This Variant Different from the September 2025 Shai-Hulud Campaign

The April 2026 variant introduces three changes: persistence beyond install-time execution through developer tooling, encrypted credential exfiltration using attacker-controlled keys and environment-aware execution controls that disable the payload in specific locales.

The move from base64 encoding to encrypted exfiltration removes simple string-based detection methods. Data is compressed and encrypted before being written to GitHub repositories, making inspection of exfiltrated content non-trivial.

Using GitHub as both the exfiltration and propagation channel allows stolen tokens to be stored, discovered, and reused through commit activity. This removes the need for separate infrastructure and embeds propagation directly into developer workflows. The use of Bun introduces execution outside the standard Node.js runtime used by most tooling. The payload is downloaded and executed as a standalone binary, shifting behavior away from environments that rely on Node-specific inspection.

The most significant shift is persistence beyond npm install. This variant modifies developer tooling configurations by injecting execution hooks into Claude Code and VS Code, allowing the payload to run when a repository is opened, not just when dependencies are installed.

Credential handling has also changed. Instead of encoding stolen data, this variant encrypts secrets using attacker-controlled keys before exfiltration, preventing inspection of stolen credentials in GitHub repositories used during propagation. The payload also includes environment-aware execution controls that terminate execution on Russian-language systems.

Indicators of Compromise (IOCs)

Scan recent npm install logs, CI execution logs and Git history for the indicators below; any match should be treated as a confirmed compromise until credentials are rotated and systems are validated.

Suspicious lifecycle scripts

• preinstall entries in package.json referencing:
  
  • setup.mjs
  • execution.js‍
  • unexpected .mjs files

"scripts": {
 "preinstall": "node setup.mjs"
}

Bun runtime execution

• Download of Bun v1.3.13 during npm install
• Network calls to Bun release URLs from CI runners or developer machines that don’t use Bun.

Credential access patterns

• Reads from:
  
  • .npmrc
  • environment variables such as NPM_TOKEN, GITHUB_TOKEN, *_API_KEY
• Execution of GitHub CLI commands, such as gh auth token during install.

Git-based indicators

• Commits containing the marker:

OhNoWhatsGoingOnWithGitHub:<base64>

• Repositories with recent commits containing base64 or encrypted blobs tied to install-time activity.

Package indicators

Presence of affected versions:

These indicators are sufficient to confirm compromise when observed in install logs, CI execution, or repository activity. As additional indicators are published by StepSecurity, Aikido, and GitHub Security Advisories, detection rules should be updated accordingly.

MITRE ATT&CK Mapping

Shai-Hulud worm activity maps to five established ATT&CK techniques across Initial Access, Execution, Credential Access, Defense Evasion and Exfiltration. The table below ties each stage of the attack chain to its ATT&CK ID for use in detection rules and reporting.

Detection and Response Playbook

If you build on Node.js or use SAP CAP, take three actions today: pin and audit @cap-js/* and mbt versions, rotate all npm and GitHub credentials used by your CI runners and disable lifecycle scripts in CI environments that do not require them.

1. Audit dependencies: Run across all repositories:

npm ls @cap-js/sqlite @cap-js/postgres @cap-js/db-service mbt

Check package-lock.json against known-good versions:

• @cap-js/sqlite@2.2.2
• @cap-js/postgres@2.2.2
• @cap-js/db-service@2.10.1
• mbt@1.2.48

2. Rotate credentials: Revoke and reissue npm tokens, GitHub Personal Access Tokens, App tokens and CI/CD secrets. Any credential present during npm install execution should be treated as compromised.
   

3. Disable lifecycle scripts in CI: Block install-time execution:

npm install --ignore-scripts

or enforce:

ignore-scripts=true

4. Hunt for IOCs

• Search Git history for: OhNoWhatsGoingOnWithGitHub
• Review CI logs for:
  
  • Bun runtime downloads
  • outbound GitHub activity during install
    

5. Audit GitHub activity: Review recent commits for injected files: setup.mjs, execution.js

• Identify repositories with: base64 or encrypted blobs and unexpected commit activity.
  

6. Monitor runtime behavior

• Detect processes reading:
  
  • .npmrc
  • environment variables containing tokens.
• Flag install-time execution that spawns external binaries.
• Alert on GitHub API usage from CI outside expected workflows.
  

7. Track upstream advisories: GitHub Security Advisories and npm advisory database.

FAQ

What is the Shai-Hulud worm?

Shai-Hulud is a self-propagating npm worm first observed in September 2025 that executes during package installation, harvests npm, GitHub, and CI/CD credentials, and uses those credentials to publish trojanized package versions and modify repositories. This propagation model allows a single compromised environment to spread the infection across multiple packages and downstream consumers.

Which npm packages are affected by the April 2026 Shai-Hulud variant?

Confirmed compromised packages include @cap-js/sqlite@2.2.2, @cap-js/postgres@2.2.2, @cap-js/db-service@2.10.1, and mbt@1.2.48. These are core dependencies in SAP CAP projects, meaning they are installed directly in development and CI workflows where credentials are available, increasing the likelihood of credential exposure and propagation.

What is a preinstall script attack?

A preinstall script attack abuses npm’s preinstall lifecycle hook, which runs automatically during npm install before lockfile validation and most security tooling executes. This allows attackers to run arbitrary code in developer or CI environments with the same permissions as the install process, making it an effective entry point for credential harvesting and further compromise.

Is the Shai-Hulud worm related to TeamPCP?

Public reporting from StepSecurity and Aikido attributes the April 2026 SAP-targeting variant to activity tracked as TeamPCP. While the original September 2025 campaign was not formally attributed, both share the same execution model of install-time code execution, credential harvesting, and automated republishing across the npm ecosystem.

How do I check if my project is compromised?

Run npm ls for the affected packages and review package-lock.json for the known compromised versions. Search Git history for the OhNoWhatsGoingOnWithGitHub marker and inspect CI logs for Bun runtime downloads or outbound GitHub activity during npm install. Any match should be treated as a confirmed compromise until credentials are rotated.

Can npm audit detect this attack?

Not reliably on day zero. npm audit depends on advisory databases that are updated after malicious versions are identified and reported. In wormable attacks like Shai-Hulud, the malicious package is often the latest published version, allowing it to spread before detection signatures or advisories are available.

Should npm lifecycle scripts be disabled in CI?

Yes. Adding npm install --ignore-scripts or setting ignore-scripts=true prevents execution of preinstall and postinstall hooks in CI environments. Since these scripts run automatically with install privileges, disabling them reduces exposure to install-time attacks. Exceptions should be explicitly reviewed and whitelisted where required.

How is this variant different from the September 2025 campaign?

The April 2026 variant targets SAP npm packages specifically, executes through preinstall instead of postinstall, encrypts exfiltrated credentials, and uses GitHub repositories for both exfiltration and propagation. These changes allow earlier execution, reduce visibility into stolen data, and embed propagation directly into trusted developer workflows.

What MITRE ATT&CK techniques are associated with this attack?

The attack maps to T1195.002 (Compromise Software Supply Chain), T1059.007 (JavaScript execution), T1027 (Obfuscation), T1552.001 (Credentials in Files), and T1567 (Exfiltration Over Web Service). These mappings align each stage of the attack chain to standardized detection and reporting frameworks used by SOC and security teams.

Where can I track updates on this campaign?

Track updates from StepSecurity, Aikido, GitHub Security Advisories and the npm advisory database as additional compromised packages and indicators are identified. These sources publish ongoing research and newly discovered IOCs as the campaign evolves across the npm ecosystem.

References

1. Aikido. April 29, 2026. Mini Shai-Hulud Targets SAP npm Packages With a Bun-Based Secret Stealer. Aikido.
2. Kodem Security. November 24, 2025. Shai Hulud 2.0: What We Know About the Ongoing NPM Supply Chain Attack. Kodem.
3. Kodem Security. December 29, 2025. Guess Who's Back: Shai-Hulud 3.0 The Golden Path. Kodem.
4. Kodem Security. February 23, 2026. SANDWORM_MODE: A New Shai‑Hulud‑Style npm Worm Threatening Developer & AI Toolchain Security. Kodem.
5. Kodem Security. When the Supply Chain Becomes the Attack Surface: Inside the TeamPCP Campaign. March 31, 2026. Kodem.
6. StepSecurity. April 29, 2026. A Mini Shai-Hulud Has Appeared: Obfuscated Bun Runtime Payloads Hit SAP-Related npm Packages. StepSecurity.
7. The Hacker News. April 29, 2026. SAP-Related npm Packages Compromised in Credential-Stealing Supply Chain Attack. The Hacker News.