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.
At a glance
What this is: This is a supply chain compromise of axios npm publishing that turned a maintainer-account takeover into cross-platform malware delivery through a malicious dependency chain.
Why it matters: It matters because IAM, CI, and software supply chain teams have to govern publishing paths, tokens, and script execution together, not as separate control problems.
By the numbers:
- The average time to mitigate a leaked secret is 36 hours, highlighting the operational burden of manual remediation processes, according to the 2024 State of Secrets Management Survey.
Context
npm package trust breaks when publishing authority, dependency resolution, and install-time script execution are treated as separate controls. In this case, a maintainer account takeover was enough to turn a routine axios upgrade path into silent code execution across developer and CI environments.
The identity lesson is straightforward: a package publisher is itself a governed identity, not just a content source. When legacy tokens coexist with trusted publishing, the older path becomes an exception channel that can bypass the controls teams assume are authoritative.
Axios is a widely used JavaScript library, so the compromise mattered not because of a flaw in axios source code, but because the package supply chain let a malicious release inherit trust from normal dependency behaviour.
Key questions
Q: What breaks when npm packages can still run postinstall hooks during install?
A: Postinstall hooks turn dependency installation into code execution, which means a package can be trusted as a library but behave like malware at install time. That breaks the assumption that source review alone is enough. Security teams should treat installer behaviour as part of the attack surface and restrict scripts in CI and build systems.
Q: Why do legacy publishing tokens create supply chain risk after trusted publishing is enabled?
A: Because legacy tokens preserve an alternate path to publish releases without the workflow identity and provenance that trusted publishing is meant to enforce. If both paths remain active, attackers only need the weaker one. Teams should remove old credentials once a modern release mechanism is in place and verify that no bypass path remains.
Q: How should teams respond when a package or maintainer account is compromised?
A: Assume any reachable credentials may be exposed, then rotate broadly across vaults, cloud secret managers, and developer tooling. The response should prioritise the credentials that could unlock other secrets, not just the first token named in the incident report.
Q: When should teams trust package provenance over dependency version numbers?
A: Only when the provenance is tied to a known workflow, the package was published through the expected release channel, and there is a corresponding source change to review. Version numbers alone do not prove legitimacy. Provenance should be used as a gating control, not an after-the-fact label on a release.
Technical breakdown
How maintainer account takeover bypassed trusted publishing
The attacker changed the axios maintainer account email, then used the npm CLI to publish poisoned versions manually. That mattered because axios normally used trusted publishing through GitHub Actions and OIDC attestations, which tie a release to a workflow identity and code change. The malicious release path bypassed that model entirely. The result is not just a compromised account, but a second publishing channel that sat outside the provenance boundary teams thought they had. Practical implication: publishing trust must be evaluated as an identity control, not only as a build integrity control.
Practical implication: revoke or eliminate legacy publishing tokens and treat release-path exceptions as governance failures.
Why the phantom dependency trick worked
The attacker did not modify axios source files. Instead, package.json was changed to add a runtime dependency on plain-crypto-js, which was never imported by the application code and existed only to trigger a postinstall hook. npm executes postinstall automatically after installation, so the malicious package gained execution during dependency resolution rather than during runtime use. This is a classic abuse of installer behaviour: a package can be trusted as data yet execute as code. Practical implication: dependency review must include install-time behaviour, not just source diffs.
Practical implication: inspect package manifests for hidden install hooks and block automatic script execution where possible.
How the dropper turned npm install into RAT delivery
Once the postinstall hook ran, the dropper decoded platform-specific payload logic, reached a C2 server, and fetched a macOS, Windows, or Linux RAT. The malicious code then disguised outbound traffic to look like npm registry communication and deleted its own setup files and manifest changes. That combination matters because detection based on source inspection or package cleanup becomes ineffective once the installer itself has executed. Practical implication: defenders need execution-level monitoring and network controls, not just repository hygiene.
Practical implication: correlate package installation events with process and network telemetry before the host is treated as clean.
Threat narrative
Attacker objective: The attacker wanted persistent remote access on developer and CI hosts while hiding the delivery path inside trusted npm installation flows.
- Entry occurred when attackers took over the axios maintainer account and used a legacy npm token to publish malicious versions.
- Credential abuse followed through the compromised publishing identity, allowing a phantom dependency and postinstall hook to execute without user interaction.
- Escalation happened when the dropper fetched a platform-specific RAT and established remote control on macOS, Windows, and Linux hosts.
- Impact was silent backdoor installation within roughly 1.1 seconds of npm install completion, with evidence destruction making cleanup and forensics harder.
Breaches seen in the wild
- CanisterSprawl npm worm 2026: The CanisterSprawl worm stole npm and PyPI publish tokens from installs of pgserve and Namastex packages and republished victims' packages.
- 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
Legacy publishing tokens are the real trust gap here: Trusted publishing did not fail as a concept, but it failed as a governance boundary because an older token still existed beside it. That means release identity was split across two pathways with different assurance levels. The practical lesson is that publishing assurance is only as strong as its weakest remaining authentication path.
Install-time execution is a distinct identity boundary: npm install did not just resolve code, it executed code through postinstall hooks. That creates a second trust decision after package selection, and most governance models still treat those as the same event. The result is a hidden execution surface that can convert a normal dependency update into immediate compromise.
Phantom dependencies are a supply chain control evasion pattern: the malicious package was not imported by axios source at all, which shows how dependency graph review can miss code that exists solely to execute during installation. This is not a code-quality problem, it is a lifecycle governance problem across publishing, packaging, and execution. Practitioners should treat unused runtime dependencies as a security signal, not a harmless anomaly.
Identity blast radius in package ecosystems is measured by downstream dependency count: axios carried roughly 100 million weekly downloads and over 174,000 dependent packages, so account compromise translated into ecosystem-wide exposure. That scale means publishing governance must be designed as infrastructure risk, not developer convenience. Teams need to know which identities can move trust downstream, and how far that trust reaches.
Package maintainer identity is part of the production attack surface: when the publisher can still sign, ship, and execute code through a legacy path, the organisation has not fully governed the identity behind the release. The attack shows that supply chain security, IAM, and CI governance are one control plane in practice. The implication is that release identity has to be lifecycle-managed like any other privileged identity.
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.
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Read next: CI/CD Pipeline Identity Security Guide
What this signals
Provenance only works when it is exclusive: trusted publishing, OIDC attestation, and workflow-linked releases are effective only if legacy token-based publishing is removed. The axios compromise shows that release identity is not secure when more than one publishing path can still write to the same package namespace.
Install-time code execution is the hidden boundary in npm ecosystems: teams often focus on source integrity, but a package can remain source-clean and still execute malicious logic through install hooks. That means CI policy has to control script execution, not just dependency resolution.
Package maintainer identity is a privileged production identity: the real blast radius came from a release identity that could reach millions of installs downstream. Governance needs to track who can publish, how they authenticate, and whether the publishing path is actually the only path.
For practitioners
- Eliminate legacy npm publishing paths Remove long-lived npm access tokens where trusted publishing is already available, and require a single release path with OIDC-backed provenance only.
- Block automatic install-time script execution Use npm install --ignore-scripts in CI/CD where feasible, then allow scripts only for packages that have been explicitly reviewed and justified.
- Review package manifests for hidden execution Inspect dependency changes for postinstall hooks, runtime-only packages, and phantom dependencies that do not appear in the application import graph.
- Rotate secrets exposed to affected hosts Treat any host that installed the poisoned versions as potentially exposed and rotate npm tokens, cloud keys, SSH credentials, and other reachable secrets.
- Validate provenance before upgrade adoption Check that package releases show the expected trusted publisher attestation, matching workflow identity, and a corresponding repository change before allowing upgrades.
Key takeaways
- The incident was a maintainer-account compromise, not a flaw in axios source code, which is why release identity and publishing path control matter more than code review alone.
- The malicious versions were exposed briefly but could still silently backdoor any project that installed them during the window, showing how quickly dependency trust can collapse.
- The control failure was the coexistence of trusted publishing with a legacy token path, because that gave the attacker an alternate route around provenance checks.
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 define the specific risk controls and attack patterns relevant to this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The compromise depended on a publishing token and install-time secret exposure risk. |
| NHI-03 — Vulnerable Third-Party NHI | The malicious dependency and maintainer account show third-party identity risk inside package supply chains. | |
| NHI-07 — Long-Lived Secrets | A classic npm token appears to have enabled the publishing bypass described in the article. | |
| Recommendation — Inventory exposed npm tokens and revoke any long-lived release credentials that can still publish packages. Assess package publishers and transitive dependencies as third-party NHIs before allowing them into production. Replace long-lived release secrets with short-lived, workflow-bound credentials wherever publishing is still required. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The incident used credential abuse to gain publishing access and then spread through downstream installations. |
| Recommendation — Map maintainer-token abuse to credential-access monitoring and track downstream lateral movement from infected build systems. | ||
Key terms
- Trusted Publishing: Trusted publishing is a release method that ties package publication to a verified CI workflow, usually with short-lived identity tokens and provenance evidence. It reduces the value of stolen legacy credentials, but only if older publish paths are fully removed and not left alongside the new flow.
- 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.
- Phantom Dependency: A phantom dependency is a package added to a software supply chain for its side effects rather than for direct use by the application. It can remain invisible in normal code paths while still executing during installation, which makes package metadata and lifecycle scripts part of the attack surface.
- Publishing Identity: The account, token, or credential set that authorises changes to a software package distribution channel. It is a privileged non-human identity because it can affect many downstream systems at once, so compromise of this identity can become an ecosystem-wide security event.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 9, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org