TL;DR: The Shai-Hulud worm has reemerged through a malicious bun_environment.js package, and several npm accounts, including @asyncapi and @posthog, appear compromised, underscoring how dependency trust can be weaponised across the SDLC, according to Veracode. Software supply chain security now depends on faster package verification, blocking, and policy enforcement, not just after-the-fact detection.
At a glance
What this is: Veracode reports a renewed Shai-Hulud npm worm campaign using a malicious bun_environment.js file and claims several npm accounts appear compromised.
Why it matters: This matters because npm trust chains can be turned into a distribution path for malware, so SDLC teams need stronger package admission, monitoring and blocklisting controls.
Context
npm package ecosystems are only as trustworthy as the publishing and installation controls around them. When a worm reappears through a package file and compromised accounts, the governance problem is not just malware detection. It is the assumption that popular packages remain trustworthy until after compromise is proven, which is too late for build pipelines and developer workstations.
This is also an identity and access problem inside the software supply chain. Compromised npm accounts act like high-value non-human identities: they publish code, inherit downstream trust, and can move malicious content into SDLC workflows before conventional scanning catches it. The article points to a recurring weakness in package trust, provenance validation, and automated blocking.
The pattern is typical for open-source supply chain abuse, but the spreading scope makes it operationally harder to contain once multiple accounts and packages are involved.
Key questions
Q: What fails when a malicious npm package reaches a mobile app build pipeline?
A: The failure is not only code integrity. A malicious package can execute during install or build, steal secrets from the environment, and persist into future releases. Once developer credentials or CI/CD tokens are exposed, the attacker can move from dependency compromise into backend access and data exfiltration without needing to breach the app directly.
Q: Why do compromised maintainer credentials make open-source supply chains so dangerous?
A: Compromised maintainer credentials let attackers move from a single tainted package to multiple packages owned by the same account or organization. That turns one infection path into a propagation mechanism. In practice, software installation becomes code execution with publishing privileges, which can expose npm tokens, GitHub secrets, and cloud keys before defenders notice the malicious release.
Q: What signs show that an npm package may be part of a worm campaign?
A: Watch for unexpected version updates, unusual obfuscation, sudden maintainership changes and repeated publication activity across related packages. Those signals often indicate the attacker is using trusted package channels to move malware through the ecosystem rather than attempting a direct exploit against each target.
Q: Why do npm supply chain attacks remain effective even when teams scan dependencies?
A: Dependency scanning is usually post hoc, while these attacks often execute at publish time or install time. If a package runs malicious code during installation, the harm can occur before a scanner has any chance to flag it. Teams need controls that inspect and gate new packages before installation.
Technical breakdown
How npm worming exploits package trust
A package worm does not need to break into every target directly. It abuses the trust that installation tools, maintainers and CI/CD systems place in package metadata and published artifacts. If an attacker compromises a maintainer account, they can publish a malicious update that looks like a normal dependency refresh. In modern JavaScript supply chains, that update may be pulled into build jobs, developer machines and downstream packages before anyone notices. The technical danger is not only code execution, but propagation through normal dependency resolution and install flows, which makes speed of detection critical.
Practical implication: treat package publication as an attack surface and verify provenance before installation, not after compromise.
Why compromised npm accounts function like non-human identities
Package maintainer accounts are non-human identities because they authenticate software actions rather than human logins. When those accounts are stolen, the attacker inherits the right to publish, update and sign distribution paths that other systems trust automatically. That is why identity governance applies here: lifecycle, ownership, scope and revocation matter even when the account is used by a developer rather than a service. Once trust is delegated to the account, every downstream consumer inherits the blast radius unless admission controls and package policy intervene.
Practical implication: inventory publish-capable accounts, reduce standing publishing rights, and revoke stale or unused package ownership paths.
How package firewalling changes the control point
A package firewall shifts protection from late-stage detection to install-time enforcement. Instead of relying on every team to spot malicious code after it lands, the control blocks known-bad or policy-violating packages from reaching the SDLC at all. That matters in worm events because a blocklist can stop repeat distribution even when the malware is already circulating across multiple accounts and package names. It also complements software composition analysis, which is useful for finding exposure but not sufficient on its own to stop first-install or re-install attempts.
Practical implication: place policy enforcement at package ingress so malicious dependencies are blocked before build and test workflows consume them.
Threat narrative
Attacker objective: The attacker objective is to distribute malware through trusted npm packages and expand reach across software delivery pipelines before defenders can block it.
- Entry occurred through compromise of npm accounts that could publish or update packages trusted by downstream consumers.
- Credentialed publishing enabled malicious package updates, including bun_environment.js, to spread through ordinary dependency installation paths.
- Impact was propagation of supply chain malware across npm consumers, with the potential to reach SDLC workflows, developers and end users.
Breaches seen in the wild
- Shai-Hulud npm worm first wave 2025: The first Shai-Hulud wave used stolen npm tokens to trojanise 500+ packages, starting with tinycolor, and leaked developer and CI secrets on GitHub.
- Bitwarden CLI npm compromise 2026: A malicious Bitwarden CLI on npm, linked to the Checkmarx campaign, targeted GitHub, npm, cloud and CI secrets from developers for 90 minutes.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
npm supply chain compromise is now an identity governance problem, not just a scanning problem. When maintainers, package publishers and CI-facing accounts are trusted to act on behalf of software teams, their compromise becomes a delegated-authority event. That makes publishing rights, revocation speed and account ownership part of SDLC security governance. Practitioners should treat package identities as governed assets, not convenience accounts.
Shai-Hulud shows how quickly package trust can outpace remediation. A malicious package only needs to win one installation path to start multiplying across developer systems and build pipelines. The central weakness is the assumption that trust can be validated after distribution, when the attacker has already used that trust to move laterally through the ecosystem. The field needs faster admission control and stronger provenance checks.
Package ingress is the real control boundary for modern software supply chains. Once malicious code reaches a repository mirror, local cache or build runner, the containment problem becomes much harder. Blocking, policy enforcement and anomaly detection all need to act before package execution, not simply after signature or static-analysis failure. Practitioners should move controls left to the point where dependency trust is first consumed.
High-trust open-source ecosystems now require blast-radius thinking. The risk is no longer limited to one malicious module or one compromised maintainer. Worm-like campaigns spread through interconnected packages and reused trust relationships, which means governance must focus on who can publish, how quickly access can be revoked, and how aggressively malicious packages can be quarantined. Teams should reduce the number of identities that can expand the blast radius.
Shai-Hulud is a useful marker for supply chain maturity gaps. Organisations that rely only on post-install detection will keep finding themselves behind the propagation curve. Mature programmes combine package inventory, admission blocking, maintainer risk review and automated response when a package or account turns suspicious. The practitioner conclusion is clear: trust management must become a runtime control, not a retrospective one.
What this signals
Package trust has become a governance boundary for SDLC teams. When malicious dependencies can arrive through normal publishing channels, the question is no longer whether scanners eventually detect them. The question is whether the organisation can stop untrusted packages before they execute in developer or CI environments.
Non-human publishing identities need lifecycle controls. If an npm maintainer account can push code into build systems, it should be governed like any other privileged identity: ownership must be clear, recovery paths must be protected, and stale access must be removed quickly.
Detection without ingress control leaves a timing gap. The practical lesson from Shai-Hulud is that package security has to combine provenance checks, allowlisting and immediate blocklist enforcement so compromise is contained at the moment of consumption, not after spread has begun.
For practitioners
- Harden package admission controls Block untrusted or newly suspicious npm packages at the point of install, and require explicit allowlisting for higher-risk dependencies.
- Review maintainer account exposure Inventory publish-capable npm accounts, remove unused ownership paths, and tighten recovery and revocation processes for any account that can push code into builds.
- Use package firewalling before build execution Place package firewall policy in front of CI and developer workflows so malicious artifacts are stopped before they can execute or transit into the SDLC.
- Pair SCA with blocklist enforcement Use software composition analysis to detect known malicious packages, then enforce automatic blocking so discovery is matched by immediate containment.
- Monitor for anomalous publishing behaviour Track sudden version churn, obfuscation and unusual package updates across your dependency estate, especially where maintainers or package names change unexpectedly.
Key takeaways
- The article shows that npm supply chain attacks keep recurring because trusted package channels remain easy to abuse once publishing identities are compromised.
- The risk is not limited to one package or one maintainer, since worm-like campaigns can spread quickly through ordinary dependency installs and build workflows.
- The most effective control shift is to stop treating package trust as a post-detection problem and enforce package admission, blocklisting and identity governance up front.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Compromised npm maintainer accounts and packages illustrate third-party non-human identity abuse. |
| NHI-05 — Overprivileged NHI | Publish rights across many packages create excessive non-human privilege and wide blast radius. | |
| Recommendation — Map publisher-owned package accounts to NHI-03 and restrict who can publish or update dependencies. Reduce package publishing scope so no single identity can update more dependencies than it needs. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The campaign uses compromised accounts to gain publish access and spread malicious code downstream. |
| Recommendation — Map maintainer compromise to TA0006 and TA0010 and hunt for abusive publishing and downstream propagation. | ||
| CIS Controls v8 | CIS-5 — Account Management | Maintainer and CI account governance is central to stopping compromised npm publishing identities. |
| Recommendation — Apply account management controls to inventory, revoke and review all package-publishing identities. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Package publishing and install permissions need tight authorization boundaries. |
| Recommendation — Enforce PR.AA-05 so only authorised identities can publish, approve or install high-risk packages. | ||
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.
- Package Admission: Package admission is the decision point where tooling or policy determines whether a dependency is allowed into a build or deployment workflow. In mature programmes, this is where trust is enforced, exceptions are recorded, and automation is constrained by policy.
- Supply Chain Worm: A supply chain worm is malware that uses one compromise to propagate into adjacent packages, repositories, or automation systems. In identity terms, it becomes far more dangerous when it can harvest and replay secrets that let it publish, move, or persist without further exploitation.
- Package provenance: Package provenance is the ability to prove where software came from, who published it, and whether it has been modified before installation. In MCP sprawl, weak provenance means installation can happen faster than trust can be established, which increases secret exposure risk.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It is designed for practitioners who need to govern delegated access, publishing rights and lifecycle control across modern security programmes.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org