TL;DR: A hijacked npm maintainer account turned Axios into a supply chain weapon, and malicious versions executed a cross-platform RAT during a two-to-three-hour exposure window, according to WorkOS. Lockfiles, provenance, and script controls help, but this incident shows that package identity trust still breaks faster than most teams can detect it.
NHIMG editorial — based on content published by WorkOS: The Axios npm supply chain attack and what developers need to know
By the numbers:
- Axios is used by over 100 million weekly npm downloads.
Questions worth separating out
Q: What breaks when a trusted npm package publisher is compromised?
A: When a trusted publisher is compromised, registry trust collapses because malicious code can arrive through a legitimate release path.
Q: Why do package registries create NHI governance risk?
A: Package registries create NHI governance risk because publishing tokens, automation accounts, and CI identities behave like privileged non-human identities.
Q: How do security teams know if install-time scripts are unsafe?
A: Install-time scripts are unsafe when they can execute automatically from packages that have not been fully trusted or provenance-checked.
Practitioner guidance
- Shorten and harden package publishing credentials Replace long-lived npm classic tokens with granular, short-lived publishing credentials, enforce MFA on maintainer accounts, and review who can publish under each package namespace.
- Block install-time execution for untrusted packages Use npm install --ignore-scripts in CI/CD where possible, and only allow lifecycle scripts for packages that have been explicitly trusted and reviewed.
- Require provenance before accepting releases Treat unsigned or non-provenanced releases as suspicious, especially when a critical package gains a new dependency or version pattern without a clear source lineage.
What's in the full analysis
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step detection commands for identifying affected lockfiles and installed packages.
- Hashes and indicators of compromise for the malicious Axios and plain-crypto-js releases.
- Immediate response steps for compromised developer or CI machines, including isolation and re-imaging.
- Specific hardening guidance for lockfiles, provenance, and npm token settings.
👉 Read WorkOS's analysis of the Axios npm supply chain compromise →
Axios compromise: what npm identity controls failed to stop it?
Explore further
Package publishing trust is a privileged NHI problem, not a developer convenience problem. The Axios incident shows that npm tokens, maintainer accounts, and release workflows function as non-human identities with real blast radius. When those identities are long-lived or weakly bound to release context, a single compromise can push malicious code at scale. The practitioner conclusion is that package publishing must be governed like any other privileged non-human access path.
A few things that frame the scale:
- 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 behaviour gap that supply chain attacks can exploit.
A question worth separating out:
Q: Who is accountable when malicious code enters through a package registry?
A: Accountability usually spans the package maintainer, the registry controls, and the consuming organisation’s build governance. The maintainer identity is the publishing control point, but the consumer still owns script restrictions, lockfile enforcement, and credential protection on build systems. The right question is who owned each control layer, not who noticed the attack first.
👉 Read our full editorial: Axios supply chain compromise exposes npm identity trust gaps