Shai-Hulud npm supply chain incident exposes secret-sprawl risk

At a glance

What this is: NHI Mgmt Group's analysis, drawing on SecurityScorecard's report: Shai-Hulud was a supply chain incident in the npm ecosystem, not a CrowdStrike internal breach, and the attack involved trojanized packages and secret theft attempts.

Why it matters: For IAM, NHI, and platform teams, the case shows how quickly package compromise turns into secrets exposure, making publish-path governance and credential containment a shared security problem.

By the numbers:

• A large npm supply chain attack trojanized over 150 JavaScript packages.

Context

The core governance gap here is not just package integrity, but the way build and publish ecosystems can expose developer secrets at the same time as they distribute malicious code. When tokens, cloud keys, and CI access sit close to package publication, compromise of one package can turn into a broader credential problem across the software supply chain.

For identity and access teams, this is a non-human identity problem as much as a software supply chain problem. Package publishing credentials, cloud keys, and automation tokens behave like NHIs when they authenticate systems and pipelines, yet they are often managed with weaker lifecycle controls than human identities.

The correction also matters because practitioners rely on incident labels to decide whether a risk is internal compromise, third-party propagation, or ecosystem-wide exposure. In this case, the starting position was atypical only in the public misdescription; the underlying attack pattern of secret-sprawl-driven supply chain abuse is now familiar.

Key questions

Q: What failure mode does the Shai-Hulud incident expose in software delivery pipelines?

A: It shows that package publishing paths can become a secret-exposure channel when the same workflows handle code release and credential-bearing automation. If tokens, cloud keys, or CI secrets are reachable from publish steps, attackers can harvest reusable access while distributing malicious updates. The control gap is separation between release authority and secret access.

Q: What are the signs that an npm-based supply chain attack is stealing credentials?

A: Look for unexpected lifecycle script execution, outbound connections after install, reads of local secret files, access to browser profile data, and new use of cloud or GitHub tokens from unusual systems. A malicious package often leaves a pattern across endpoint telemetry, secrets access logs, and identity provider audit trails rather than one obvious alert.

Q: What are the signs that secret sprawl is making a supply chain attack worse?

A: Look for publishing tokens embedded in scripts, secrets stored in CI variables without ownership, credentials appearing in logs or caches, and the same access material used across multiple environments. Those patterns indicate that revocation will be slow and blast radius will be wide if a package or pipeline is compromised.

Q: How should teams handle accountability when a supply chain incident is misdescribed as a direct breach?

A: Treat the incident taxonomy itself as a governance control. Response, supplier assurance, and executive reporting all change depending on whether the compromise is inside the organisation or in an upstream ecosystem. Clear ownership for incident validation prevents bad labels from driving the wrong containment and communication decisions.

Technical breakdown

How npm supply chain compromise spreads through package publishing

npm package compromise often starts with one malicious or hijacked release and then propagates through trusted update paths. Attackers do not need to own the target organisation if they can insert code into a dependency that downstream developers install automatically. In this pattern, the package registry becomes an execution and distribution layer, while the real objective is often to reach developer endpoints, CI runners, or secrets stores that sit beside the build process. That is why package integrity and publisher trust are inseparable from credential protection.

Practical implication: Treat package publishing access and dependency trust as part of the same control plane, not separate problems.

Why secret sprawl turns build systems into identity targets

Secret sprawl means credentials, tokens, and keys are present in more places than the organisation can reliably inventory or revoke. In supply chain incidents, attackers frequently target these secrets because they unlock cloud consoles, code repositories, and automation pipelines long after the original package has been detected. The problem is not only exposure, but persistence: once a token is distributed across local developer machines, CI logs, caches, or scripts, revocation becomes slower and less certain. That is what makes software delivery paths a non-human identity governance issue.

Practical implication: Inventory and govern publishing tokens, cloud keys, and pipeline secrets as NHIs with explicit ownership and revocation paths.

Why malicious updates are effective even without direct network intrusion

Malicious package updates exploit trust in the software ecosystem rather than classic perimeter weakness. If a build system consumes a compromised package, the update can run in a privileged environment that already has access to source code, artifact stores, and deployment credentials. This removes the need for an external intrusion step inside the target network. The attack surface is therefore defined by what the build and release process can reach, which is why secret placement and pipeline permissions matter as much as code scanning.

Practical implication: Reduce the blast radius of build environments by separating package ingestion from credential-bearing deployment steps.

Threat narrative

Attacker objective: The attacker aimed to harvest reusable developer and cloud credentials while amplifying reach through trusted package distribution.

1. Entry occurred through a trojanized npm package published into the ecosystem and consumed by downstream users and pipelines.
2. Credential access followed as the malware attempted to steal developer secrets, including tokens and cloud keys.
3. Impact emerged through malicious package propagation, with the incident spreading across the npm ecosystem rather than a single organisation's network.

Breaches seen in the wild

• 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.
• 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.

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

Secret sprawl is now a supply chain exposure, not just a hygiene issue. When developer tokens and cloud keys sit near package publishing paths, compromise of one ecosystem component can expose authentication material across many downstream systems. That changes the governance question from simple secret rotation to control over where secrets are allowed to exist at all. Practitioners should treat build-path credential containment as a core supply chain control.

Package registries have become identity infrastructure by proxy. The article shows that npm publishing flows can carry both code and access authority, which means package trust and credential trust are now coupled. That coupling is especially relevant for NHIs because automation tokens and service credentials often outlive the code paths they were meant to support. Teams need to govern publisher identities with the same seriousness they apply to privileged operational accounts.

Publish-path privilege: the failure mode is allowing secrets to remain reachable from systems that can also distribute code. That is the governance assumption the incident exposes, and it is weaker than many organisations realise. If an attacker can reach both package release and secret material through the same workflow, containment is already too late. Practitioners should redesign around separation of duties between code publication and credential-bearing automation.

Incident accuracy is part of security governance. SecurityScorecard’s correction matters because mislabelling a supply chain event as a direct breach can mislead response priorities, third-party assessment, and executive reporting. Precision about where the compromise occurred determines whether teams focus on internal containment, supplier assurance, or ecosystem-level exposure. The practitioner lesson is to maintain review controls for incident communications as carefully as for technical controls.

This pattern validates the OWASP-NHI lens for software delivery. Secret leakage, long-lived tokens, and overprivileged automation remain the recurring failure modes in package and pipeline compromise. The broader market signal is that NHI governance is no longer separate from DevSecOps, because the identities that matter most may be the ones operating the build and publish chain. Security teams should map these workflows explicitly to NHI controls and supply chain policy.

From our research library:

• 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
• The blast radius of the Salesloft-Drift OAuth supply chain attack was 10 times greater than earlier incidents in which attackers breached Salesforce directly.
• Read next: AI Supply Chain Security and AI-BOM Guide

What this signals

Publish-path privilege is the hidden governance gap in many npm incidents. When the same workflow can release code and reach cloud keys, the attacker does not need to break two controls. They only need the weaker of the two. That is why separation between publishing authority and secret-bearing automation should now be treated as a board-visible supply chain control.

The incident also reinforces that NHI governance belongs inside DevSecOps rather than beside it. Package signing, CI runner access, and deployment tokens are all identity problems once they can authenticate machines and automation. Teams that classify these as mere engineering secrets will keep underestimating their blast radius.

Treat package ecosystems as identity planes as well as software distribution channels. The practical change is to map publish-time access, runtime secrets, and revocation ownership into one control view before a malicious update turns into ecosystem-wide credential exposure.

For practitioners

• Separate package publishing from secret-bearing automation Keep release pipelines, signing steps, and credentialed deployment actions in distinct trust zones so one compromise cannot expose both code distribution and cloud access.
• Inventory publishing tokens and cloud keys as NHIs Assign owners, expiry dates, and revocation procedures to every token used in npm publishing, CI, and deployment workflows.
• Restrict developer and CI secret exposure Remove long-lived credentials from local scripts, logs, caches, and build artefacts, then scan for hidden copies across the delivery path.
• Add review controls for incident communications Require threat intelligence and communications approval before issuing incident statements so ecosystem events are not mislabelled as internal breaches.

Key takeaways

• The incident is best understood as a supply chain compromise that sought developer secrets and cloud keys, not as a direct internal breach.
• Trojanized npm packages become especially dangerous when secret sprawl places reusable credentials near build and publish workflows.
• The most effective control is structural separation between package release authority and the automation that holds or reaches sensitive credentials.

Key terms

• Secrets Sprawl: The uncontrolled proliferation of sensitive credentials, API keys, tokens, passwords, certificates, across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
• Publishing-path privilege: Publishing-path privilege is the effective authority to move code from source control into a registry, package feed or release channel. It matters because attackers do not always need production access. If they can control the release path, they can insert malicious code into trusted distribution flows.
• 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.
• Supply Chain Propagation: Supply chain propagation is the spread of malicious code or trust abuse from one compromised package, account, or dependency into multiple downstream systems. The key risk is that trusted distribution mechanisms amplify impact faster than traditional endpoint or perimeter controls can respond.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle fundamentals. It helps practitioners connect identity control to the broader security programmes that software delivery now depends on.