Notifications
Clear all
Topic starter
23/06/2026 9:15 pm
TL;DR: A compromised axios maintainer account published two malicious npm versions that installed a cross-platform RAT within minutes of npm install, affecting a library with roughly 100 million weekly downloads and over 174,000 dependents, according to Orca Security. Trust controls fail when legacy publishing paths and postinstall execution remain available alongside modern provenance.
NHIMG editorial — based on content published by Orca Security covering the axios npm supply chain compromise: malicious package versions installed a RAT through a maintainer account takeover
By the numbers:
- Axios is one of the most widely used JavaScript libraries, with roughly 100 million weekly downloads and over 174,000 dependent packages.
Questions worth separating out
Q: How should security teams stop npm supply chain attacks from running during install?
A: Block automatic lifecycle script execution in CI where the workflow can tolerate it, then allow only packages with verified provenance and explicit release evidence.
Q: Why do compromised maintainer accounts create such large NHI risk in software pipelines?
A: Because maintainer identities often carry publishing rights, token access, and build trust all at once, so one compromise can reach many downstream systems.
Q: What do teams get wrong about dependency provenance and package trust?
A: Teams often assume a signed or expected package name is enough, but package metadata, lifecycle hooks, and publishing path all matter.
Practitioner guidance
- Remove legacy publishing paths immediately Retire long-lived npm tokens and require a single provenance-backed publishing method for every release workflow.
- Disable install-time script execution where possible Use npm install --ignore-scripts in CI/CD and validate any package that depends on lifecycle hooks before allowing it into build pipelines.
- Audit dependency provenance at release time Check whether new package versions have a corresponding commit, tag, and trusted publisher attestation before you allow automated updates.
What's in the full article
Orca Security's full analysis covers the operational detail this post intentionally leaves for the source:
- Package hashes and host-level indicators for validating whether [email protected] or [email protected] was executed
- Version-specific remediation steps for teams pinned to axios 1.x or the legacy 0.x branch
- Detection commands and workflow checks for confirming whether install-time payloads spawned child processes
- Post-compromise guidance for rebuilding affected systems and deciding which secrets to rotate first
👉 Read Orca Security's analysis of the axios npm supply chain compromise →
Axios supply chain compromise: what IAM and CI teams missed?
Explore further
25/06/2026 2:27 am
Legacy publishing credentials are the real control failure here. Trusted Publishing only protected the route that used OIDC-backed CI workflows, but the attacker used a different publish path through an exposed maintainer identity. That is a lifecycle and privilege separation failure, not a code vulnerability. The practical conclusion is that provenance controls do not hold if older publishing methods remain available.
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, which helps explain why build and dependency workflows stay exposed longer than teams expect.
A question worth separating out:
Q: Who is accountable when a compromised package exposes cloud or developer secrets?
A: Accountability sits with the teams that own maintainer credential governance, release controls, CI/CD hardening, and secret rotation. If a compromised dependency touched systems with sensitive credentials, the response must include revocation, reconstruction, and post-incident access review. Software supply chain incidents are identity incidents, not just build failures.
👉 Read our full editorial: Axios maintainer compromise shows how npm trust fails
