Axios maintainer compromise shows how npm trust fails

At a glance

What this is: This is an analysis of the axios npm supply chain compromise, where a maintainer account takeover enabled malicious package versions that silently deployed a RAT through dependency installation.

Why it matters: It matters because CI/CD, developer workstations, and production build pipelines all inherit the same NHI trust problem when package publishing, dependency resolution, and secret access are weakly governed.

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.

👉 Read Orca Security's analysis of the axios npm supply chain compromise

Context

The core problem is supply chain identity, not just package integrity: a trusted maintainer account can become a delivery path for malicious code when publishing credentials are stolen or legacy tokens remain active. In npm ecosystems, a dependency update can execute automatically during install, which turns account compromise into runtime compromise.

This incident sits squarely in NHI governance because the maintainer account, publish token, and build pipeline each represent a non-human identity with distinct lifecycle and privilege boundaries. When those boundaries blur, provenance controls, postinstall hooks, and downstream dependency trust collapse together rather than failing one at a time.

Axios is a familiar example because it is embedded deeply enough that a short exposure window can reach many systems at once. That makes the starting position typical of modern open-source dependency risk, not an edge case.

Key questions

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. The key control is to treat package install as code execution, not as a harmless fetch step. That approach reduces the chance that a phantom dependency can trigger malware during dependency resolution.

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. When legacy tokens remain active beside modern CI provenance, the account can bypass the very controls meant to protect release integrity. That makes lifecycle and token governance central to supply chain security.

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. A malicious release can keep the codebase looking normal while shifting the real risk into install-time execution. Provenance checks must therefore cover who published, how it was published, and what scripts will run.

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.

Technical breakdown

Maintainer account takeover and publishing-path bypass

The compromise began when the attacker took over the primary maintainer account and used it to publish malicious versions directly. The important technical detail is that legitimate releases used Trusted Publishing through GitHub Actions with OIDC-backed attestations, while the malicious versions were uploaded manually through a different path. That means the security model relied on provenance only for one publishing route, not for the whole identity surface. A long-lived classic token likely provided the bypass because it can remain valid outside the CI workflow that Trusted Publishing expects.

Practical implication: remove legacy publishing credentials wherever provenance-based release controls are in use.

Phantom dependency and postinstall execution

The attacker did not alter axios source code. Instead, they added a new dependency that was never imported by the application but still ran because npm executes postinstall hooks automatically. That creates a phantom dependency: code that exists solely to trigger during installation rather than at runtime. This pattern is hard to spot with ordinary code review because the malicious behaviour is in package metadata and lifecycle scripts, not in the visible application path. In dependency-heavy ecosystems, the install phase becomes an execution boundary, not a passive download step.

Practical implication: treat package lifecycle scripts as executable code and govern them as such.

Cross-platform dropper and anti-forensic cleanup

Once executed, the dropper identified the host platform, fetched a matching payload, and launched a RAT that supported command execution and filesystem enumeration. The payloads were tailored for macOS, Windows, and Linux, and the dropper then removed its own setup files and replaced the malicious manifest with a clean one. That means investigators looking only at the final filesystem state would miss the execution chain unless they had install-time telemetry. The attack architecture therefore couples platform-specific payload delivery with deliberate evidence destruction.

Practical implication: collect install-time telemetry and process-tree records before the filesystem can self-clean.

Threat narrative

Attacker objective: The attacker aimed to turn a trusted open-source dependency into a covert execution channel for persistent remote access and downstream credential exposure.

1. Entry occurred when the attacker took over the maintainer account and used trusted publishing gaps plus legacy credentials to publish malicious package versions.
2. Credential access was converted into execution by adding a phantom dependency whose postinstall hook ran automatically during npm install.
3. Impact followed when the dropper fetched a platform-specific RAT, established C2 beaconing, and removed evidence of its own execution.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Package install is an execution boundary, not a file transfer. npm postinstall hooks let code run as soon as a dependency lands, which means the attack surface begins before the application starts. This is why dependency trust and runtime execution cannot be separated in modern JavaScript supply chains. Security teams need to treat package metadata, lifecycle scripts, and dependency resolution as part of the same identity and access problem.

Phantom dependency is the right named concept for this breach pattern. The malicious code lived in a package that the application never imported, yet it still executed because the platform automatically honored install scripts. That means hidden dependency edges can become operational access paths even when source code reviews look clean. For practitioners, the governing problem is invisible execution through trusted package mechanics.

This incident validates NHI governance as supply chain governance. The maintainer account, publish token, CI identity, and downstream dependency all behaved as non-human identities with different trust states. When one of those identities is compromised, the blast radius extends through build systems, developer machines, and secret stores. The field should treat package publishing and dependency execution as NHI lifecycle events, not as isolated software engineering tasks.

OWASP-NHI and NIST CSF align directly to the failure mode exposed here. The control gap was not a missing alert, but a mismatched trust model around secret-bearing identities and automated execution. That maps cleanly to credential governance, least privilege, and software supply chain protection. Practitioners should use this pattern to challenge whether their non-human identities are still carrying unnecessary standing privileges.

From our research:

• 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.
• For a broader NHI breach lens, review the 52 NHI breaches Report for recurring patterns in credential exposure, over-privilege, and downstream impact.

What this signals

Phantom dependency attacks show that npm lifecycle controls now sit inside the identity plane, not outside it. When package installation can execute code, build security and NHI governance become the same conversation. Teams should expect more pressure to prove publishing provenance, script suppression, and install-time telemetry together rather than as separate controls.

With 44% of developers following secrets best practices, per The State of Secrets in AppSec, the operational gap is not awareness but execution discipline across the delivery chain. That means secrets exposed in pipelines remain a governance issue long after the package incident itself is closed.

For teams mapping this to standards, NIST Cybersecurity Framework 2.0 and OWASP Non-Human Identity Top 10 both point to the same future state: tighter control over non-human trust paths before automation turns them into attack paths.

For practitioners

• Remove legacy publishing paths immediately Retire long-lived npm tokens and require a single provenance-backed publishing method for every release workflow. If a maintainer account can still publish outside CI, the trust model is already split.
• 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. This reduces the chance that a phantom dependency can execute during install.
• 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. A release without matching provenance evidence should be treated as an identity anomaly.
• Search for install-time indicators of compromise Review CI logs, process trees, and host telemetry for package installation events that spawned unexpected shell, PowerShell, or Python processes. Focus on evidence that the install phase launched child processes or wrote temporary dropper files.
• Rotate secrets exposed to build environments Assume npm tokens, cloud keys, SSH material, and application secrets reachable from affected systems may have been exposed. Revoke and reissue them after validating which runners, developer machines, or containers executed during the window.

Key takeaways

• The axios compromise shows how one maintained package account can turn open-source distribution into a remote execution channel.
• The scale was amplified by a library with about 100 million weekly downloads and a poison window short enough to evade casual detection.
• The control that mattered most was identity and publishing governance, because legacy tokens and install-time scripts made the compromise operational.

Key terms

• 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.
• 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.
• Non-Human Identity: A non-human identity is any machine- or workload-bound identity used by software, services, automation, or build systems. In supply chain contexts, it includes maintainer tokens, CI identities, and package publishing credentials, all of which must be governed as lifecycle-bearing access assets.

Deepen your knowledge

NHI supply chain governance and secret lifecycle controls are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are securing package publishing, CI identities, or dependency execution paths, it is worth exploring.

This post draws on content published by Orca Security covering the axios npm supply chain compromise: malicious package versions installed a RAT through a maintainer account takeover. Read the original.