Shai-hulud npm malware now targets SAP-related package pipelines

At a glance

What this is: StepSecurity describes a new npm supply chain campaign that used preinstall hooks, Bun runtime execution, and obfuscated payloads to compromise SAP-related packages and steal credentials.

Why it matters: It matters because build pipelines, developer machines, and NHI controls now overlap, so teams need to govern package trust, token scope, and persistence paths together.

By the numbers:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read StepSecurity's analysis of the SAP-related Shai-Hulud npm supply chain attack

Context

A malicious npm package is not just a software supply chain issue when it can steal tokens, persist in repositories, and propagate through CI/CD. In this case, the primary security gap is that installation-time code still receives too much trust, while build credentials and developer secrets remain reachable at the exact moment packages are introduced. For NHI governance, that means npm tokens, GitHub tokens, and CI secrets are part of the same identity attack surface.

The article also shows how modern package compromise now reaches beyond classic dependency poisoning. The malware used workflow injection, repository persistence, and AI coding-agent hooks, which turns a simple install event into a multi-channel identity abuse problem. That is typical of current supply chain attacks, not an outlier, and it is why runtime visibility and secrets governance have to move together.

Key questions

Q: What breaks when a malicious npm package can read developer secrets during install?

A: The main failure is that package execution inherits identity context it should never need. Once a malicious install can read environment variables, local files, and CI secrets, it can steal credentials that survive beyond the original infection. That turns a code dependency problem into an access-control incident, because the attacker gains reusable authentication material, not just a one-time foothold.

Q: Why do stolen CI tokens and publishing tokens create such a large blast radius?

A: Because they are non-human identities with operational authority, not just authentication artifacts. A single token can publish malicious versions, create branches, trigger workflows, or read repository state. When scope is broad or lifecycle is weak, compromise spreads faster than manual review can contain it. Narrow scope and rapid revocation are essential.

Q: What do security teams get wrong about AI coding-agent persistence?

A: They often treat IDE and agent configuration as workspace convenience rather than execution surface. If malware can plant session-start or folder-open hooks, simply cleaning package artifacts is not enough. Teams need to scan developer tooling paths, repository branches, and agent configs with the same seriousness they apply to build scripts.

Q: Who is accountable when a poisoned package steals secrets from a build environment?

A: Accountability usually spans platform engineering, security, and the owners of the credential-bearing workflow. If developer tools can bypass central controls, the governance failure is shared. Frameworks such as NIST CSF and NIST SP 800-53 push organisations toward clearer control ownership, especially where machine credentials and software supply chains overlap.

Technical breakdown

How preinstall hooks turn package install into code execution

npm preinstall hooks execute before normal dependency installation completes, which gives malicious packages a high-trust execution point during setup. In this case, the hook downloaded the Bun runtime, then used it to run a large obfuscated payload outside the expected Node.js monitoring path. That matters because defenders often inspect application code after install, while the real risk occurs before the package is fully trusted. The hidden loader can still leave a working CLI in place, which reduces user suspicion and delays investigation.

Practical implication: block or tightly monitor package install scripts, especially for newly published versions and packages that can execute before policy checks finish.

Why token theft becomes worm propagation in npm ecosystems

Once a malicious package steals a developer or CI token, it can move from a single compromise to broad supply chain propagation. The attacker can publish poisoned versions, create repositories, or inject workflows using credentials that already carry package or repo scope. That is the core NHI problem here: the token is the identity, and its scope determines the blast radius. If that token is long-lived, over-scoped, or reused across publishing and automation, one successful install can become a self-expanding trust failure.

Practical implication: separate publishing, build, and repo-management credentials, and treat every npm token as a high-risk non-human identity with narrow scope and short lifetime.

How AI coding-agent hooks extend persistence beyond the build

The payload did not stop at credential theft. It also planted Claude Code and VS Code configuration files so that opening a repository could trigger the malware again. That is a significant shift because the persistence layer is no longer only the CI runner or the package registry. It now includes developer tooling that can re-execute malicious actions whenever the repo is opened. In practice, this blurs the line between supply chain compromise and workspace compromise, and it creates a second execution path that traditional package review will miss.

Practical implication: include IDE configuration files and AI coding-agent hooks in code review, repository scanning, and incident response scope.

Threat narrative

Attacker objective: The attacker aimed to steal reusable secrets and turn each compromise into further package and repository propagation.

1. Entry began with a compromised npm package or stolen npm token, then a preinstall hook executed a loader that fetched Bun and launched the payload.
2. Escalation occurred when the malware read runner memory and harvested secrets, then used GitHub and npm credentials to publish, inject, or persist across repositories.
3. Impact was worm-like propagation, repository contamination, and exposure of developer, CI/CD, and publishing credentials across the affected SAP package ecosystem.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Shai-Hulud has become a governance pattern, not just a malware name. The important shift is that package compromise now combines registry trust, CI/CD secrets, and developer workspace persistence in one chain. That means organisations cannot treat npm hygiene, secret rotation, and endpoint controls as separate programmes when the attacker can move across all three in a single install. The practitioner conclusion is to govern package execution as identity security.

Package tokens are non-human identities with operational reach. A publishing token, GitHub token, or workflow credential is not just an access artifact. It is an NHI that can publish code, create branches, trigger workflows, and spread compromise if it is too broad or too persistent. The governance failure here is standing credential exposure inside automation paths, which is exactly where NHI controls must be strongest. Practitioners should classify every automation token by blast radius and lifecycle.

AI coding-agent persistence widens the supply chain attack surface. When malware plants Claude Code or VS Code hooks, the attacker is no longer relying on one install event. They are creating a re-entry mechanism in the developer environment that can survive normal package cleanup. That makes AI-assisted development part of the security boundary, especially where repo-opening actions can execute code. The conclusion is to treat agent configuration as governed runtime state, not harmless workspace metadata.

Secret-stealing campaigns are now optimized for speed and reuse. StepSecurity’s account of rapid detection shows how quickly defenders must identify exposed credentials before they are republished or reused. The broader lesson is that leaked secrets are not single events but propagation fuel. That aligns closely with OWASP Non-Human Identity Top 10 concerns around secret sprawl and overprivilege. Practitioners should assume that one compromised package can imply multiple downstream identity exposures.

Named concept: credential propagation persistence. This attack illustrates a failure mode where stolen automation credentials are immediately reused to plant new execution paths and expand compromise. The concept matters because the attacker is not only harvesting secrets, but converting them into persistence and propagation. For identity programmes, that means lifecycle controls must cover what a token can do after it is stolen, not just whether it exists.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• This reinforces the need to pair secrets governance with 52 NHI Breaches Analysis and runtime detection, because compromised credentials can persist well beyond initial discovery.

What this signals

The practical signal for identity teams is that package ecosystems are now an NHI governance problem as much as an AppSec problem. A credential that can publish, trigger, or exfiltrate is part of the identity estate, and its lifecycle needs the same scrutiny as any privileged service account. That is why secret rotation alone is insufficient if install-time execution remains open.

Credential propagation persistence: this is the failure mode where a stolen automation token is immediately reused to plant new execution paths, making cleanup harder than revocation. The response is to connect package admission, repo scanning, and secret lifecycle management into one control loop, then validate against OWASP Non-Human Identity Top 10 and MITRE ATT&CK Enterprise Matrix.

For programmes running AI-assisted development, agent hooks and IDE automation should be treated as governed execution paths. That means code review must extend beyond source files into workspace state, workflow definitions, and tool integrations. The more repositories depend on auto-run behaviour, the more important it becomes to reduce standing privilege and to make secret exposure visible within minutes, not days.

For practitioners

• Block install-time code execution by policy Enforce controls that flag or block preinstall and postinstall hooks for newly introduced or recently published npm packages, especially in CI/CD and privileged developer environments. Pair this with alerting on unexpected use of Bun, shell, Python, or process-memory access during package installation.
• Split publishing and build credentials Use separate non-human identities for package publishing, repository administration, and CI execution. Keep each credential on the narrowest possible scope, rotate them independently, and remove any token that can both publish code and access workflow secrets.
• Scan repositories for persistence files Add detection for .claude/settings.json, .vscode/tasks.json, and similar developer-tooling artifacts in source control. Treat these files as active execution paths when they contain repo-open or session-start hooks, not as benign configuration.
• Audit affected developer and runner estates Search every enrolled developer device, CI runner, and package cache for the compromised package names and versions, then rotate any GitHub, npm, cloud, or SSH secrets that were reachable from those environments.
• Pin versions and quarantine suspicious releases Pin dependency versions where operationally possible and quarantine any package version that appeared unexpectedly or outside normal release governance. Review install provenance before allowing the package back into trusted build paths.

Key takeaways

• This attack shows that npm supply chain compromise now spans package trust, token theft, and developer workspace persistence in one chain.
• A leaked automation secret is not a one-off event if it can be reused to publish, inject workflows, or reinfect repositories.
• Teams need one control model for packages, CI/CD, and NHI lifecycle management, because separating those controls leaves the propagation path open.

Key terms

• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• Preinstall Hook: A preinstall hook is package code that runs before an application installs or starts. In supply-chain attacks, it becomes a hidden execution point that can steal secrets, alter environments, or drop further payloads before normal controls see the package's behaviour.
• Credential Propagation Persistence: Credential propagation persistence is a failure mode where stolen secrets are not only abused once, but are reused to create new execution paths that keep the compromise alive. It combines secret theft with repeated re-entry into repositories, pipelines, or developer tools, making containment harder.
• AI Coding-Agent Hook: An AI coding-agent hook is a configuration trigger that runs actions when an agent session starts or when a repository opens in a connected tool. If abused by malware, it can re-execute malicious code and turn a one-time compromise into recurring persistence.

What's in the full analysis

StepSecurity's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step runtime trace from Harden-Runner showing how the malicious preinstall hook executed inside GitHub Actions.
• Decoded loader and payload analysis, including how Bun was used to evade common Node.js monitoring paths.
• Exact repository injection behaviour, including the workflow branch names and commit patterns used to persist and spread.
• Cleanup guidance for specific compromised package versions and affected developer machine estates.

👉 StepSecurity's full post covers the runtime trace, injected workflow details, and package-specific cleanup steps.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It gives security practitioners a practical way to connect automation credentials, privileged access, and incident response.