Axios npm compromise shows how maintainer hijack becomes malware delivery

At a glance

What this is: This is a supply chain compromise of the axios npm package, where a hijacked maintainer account was used to publish malicious versions that deployed a cross-platform RAT.

Why it matters: It matters to IAM, PAM, and NHI teams because stolen maintainer tokens, publisher trust, and CI/CD secrets all sit on the same identity control plane as software release workflows.

By the numbers:

• axios has ~100 million weekly downloads.

👉 Read Aikido's analysis of the axios npm maintainer hijack and RAT deployment

Context

A supply chain compromise becomes an identity problem when release trust depends on a maintainer account, an access token, or a trusted publishing path. In this case, the primary failure was not code quality alone, but the abuse of publisher identity to move a malicious package into a widely consumed dependency chain.

For IAM and NHI practitioners, npm maintainer accounts, CI/CD tokens, and trusted publisher bindings are non-human identities with lifecycle and assurance requirements. The axios incident is a strong example of why software release governance now depends on credential control, not just package review.

Key questions

Q: What breaks when a package maintainer account is compromised?

A: When a maintainer account is compromised, the attacker inherits trusted publishing rights and can turn legitimate release channels into malware distribution paths. That breaks the assumption that package provenance is tied to a stable, accountable identity. The result is not just one bad package, but potentially broad downstream exposure across automated build and install pipelines.

Q: Why do maintained software identities need IAM-style governance?

A: Because package publishers, CI tokens, and trusted publishing bindings function like non-human identities with privileged actions and lifecycle risk. If those identities are not scoped, rotated, and monitored, they become a direct path for supply chain compromise. Treating them as operational convenience objects leaves the software release path under-governed.

Q: How do security teams know if dependency controls are actually working?

A: Look for whether build systems prevent unauthorised version drift, whether package provenance is checked before install, and whether secret-handling code is isolated from broad application reach. If packages can change quietly and still access sensitive material, the control model is failing even if scans are passing.

Q: What should teams do after a malicious npm package has run in CI/CD?

A: Contain the build environment, assume secrets on that system are exposed, and rebuild from a known-good baseline before restoring access. Then rotate npm tokens, cloud keys, SSH keys, and pipeline secrets that were reachable from the compromised host. The goal is to remove attacker persistence before any cleanup can be trusted.

Technical breakdown

How the maintainer account hijack enabled malicious package publication

The attacker first gained control of the primary maintainer's npm account and changed the email before publishing two malicious axios versions. That matters because npm package publication is an identity-authorised action, not just a code upload. The compromise bypassed repository commit history because the attacker used the registry account directly, while legitimate releases were normally tied to GitHub Actions and OIDC trusted publishing. When publisher identity is stolen, provenance checks based only on source control can miss the malicious release path.

Practical implication: bind package release approval to separate publisher identity controls, not only repository access.

Why the malicious dependency chain survived post-install inspection

The malicious axios releases added plain-crypto-js as a dependency solely to trigger a postinstall hook that executed a dropper. The dropper then fetched platform-specific payloads for macOS, Windows, and Linux, while deleting itself and replacing its package.json with a clean stub. This is a classic supply chain tradecraft pattern: use a benign-looking dependency graph to hide execution, then remove obvious filesystem evidence. Detection therefore has to look at registry history, install logs, and runtime artifacts, not just the final node_modules state.

Practical implication: preserve build logs and install telemetry, because post-execution inspection alone will miss self-deleting droppers.

What trusted publishing and package-age controls change in practice

The article shows a split between normal trusted publishing and a manually published malicious release, which means release assurance needs more than a single trust signal. A minimum package age policy can also reduce exposure to newly staged malicious dependencies, because the attacker relied on a dependency that existed for less than a day before being pulled into axios. In other words, provenance, publisher identity, and time-based validation are complementary controls, not interchangeable ones.

Practical implication: combine trusted publishing with minimum package age policies and dependency allowlisting.

Threat narrative

Attacker objective: The attacker aimed to gain persistent access to developer and build environments through a trusted dependency, then harvest credentials and establish remote control.

1. Entry occurred when the attacker hijacked the npm maintainer account and used stolen publisher identity to publish malicious axios versions.
2. Escalation happened when the malicious releases pulled in plain-crypto-js, whose postinstall hook deployed a RAT across macOS, Windows, and Linux.
3. Impact followed when the dropper self-deleted, leaving compromised developer systems and potential access to credentials, CI/CD secrets, and keys.

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

Publisher identity is now a security control, not an administrative detail. This incident worked because the attacker controlled the identity used to publish software, not because the package code itself looked obviously malicious. That is exactly the kind of control gap that NHI governance is meant to close. When release authority is treated as a low-friction operational task, tokens and maintainer accounts become high-value NHI assets with weak lifecycle oversight.

Trusted publishing reduces one class of risk, but it does not eliminate the release-chain attack surface. The malicious axios versions bypassed ordinary source history expectations by arriving through registry publication. That means software teams need provenance controls, separation of duties, and registry-side monitoring together. For practitioners, the lesson is to govern the release path as a distinct identity plane.

Minimum package age is a practical response to dependency weaponisation. The attacker relied on a newly staged package that existed briefly before being consumed by the compromised maintainer release. Age-based gating will not stop every attack, but it creates a useful friction layer against fast-turnover malicious dependencies. Practitioners should treat this as a control for untrusted freshness, not a substitute for verification.

Standing credential exposure is the failure mode this breach makes visible. A stolen maintainer token or account did not just expose one package, it exposed the distribution channel for a package with roughly 100 million weekly downloads. That is a governance failure in the same family as unmanaged service accounts and over-privileged automation. The practitioner conclusion is straightforward: release identities need the same scrutiny as production service identities.

From our research:

• axios has ~100 million weekly downloads, according to The State of Secrets in AppSec.
• Companies are dedicating an average of 32.4% of their security budgets to secrets management and code security, with US organisations leading at 40.8%, according to The State of Secrets in AppSec.
• For a broader breach pattern, see The 52 NHI breaches Report for recurring identity and credential abuse paths that mirror supply chain compromise.

What this signals

Release identity is becoming a first-class governance domain. As package ecosystems keep concentrating reach into a small set of maintainers, the real programme risk shifts from only dependency hygiene to publisher assurance, token control, and build-path verification. Teams should expect more attacks that abuse non-human identities in software delivery rather than attack the codebase directly.

Credential exposure windows now matter at registry speed. When malicious releases can propagate before local inspection catches them, the useful control point moves earlier in the chain. Pair registry monitoring with NIST SP 800-53 Rev 5 Security and Privacy Controls and package-age enforcement so compromised identities cannot translate into immediate distribution.

Build security and NHI governance are converging. The same lifecycle problems that affect service accounts also affect maintainer accounts, CI tokens, and automation identities. Organisations that already struggle with secrets sprawl should treat software publishing as part of their identity perimeter, not a separate DevOps concern.

For practitioners

• Separate release identity from source-code identity Require package publication through trusted publisher bindings and distinct approval paths so a stolen maintainer account cannot directly push registry releases. Apply step-up verification for publish actions on high-reach packages and audit who can rotate the publishing credential.
• Enforce minimum package age in CI/CD Block newly published dependencies until they have aged beyond a defined threshold, especially for transitive packages introduced during install. Use this as a friction control against dependency staging and fast malicious follow-on publications.
• Preserve install-time evidence before cleanup occurs Capture package install logs, dependency trees, and build telemetry centrally, because self-deleting droppers can remove local filesystem evidence after execution. Treat missing artifacts as an investigation trigger, not proof of safety.
• Rotate every credential reachable from affected systems Assume npm tokens, cloud keys, SSH keys, and CI/CD secrets on impacted developer hosts may have been exposed. Rebuild from known-good images, then rotate credentials after containment rather than attempting in-place cleanup.

Key takeaways

• The axios compromise shows that maintainer identity is now part of the software attack surface, not just an access-management detail.
• A package with roughly 100 million weekly downloads demonstrates how quickly a single stolen publishing identity can create broad downstream risk.
• The most effective control set combines trusted publishing, dependency-age gating, central log retention, and credential rotation after exposure.

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.
• Postinstall Hook: A script that runs automatically after a package is installed. Attackers abuse it because it executes during normal dependency installation, often before reviewers notice anything unusual, which makes it a common delivery mechanism for malware in package ecosystems.
• Package Age Gating: A control that delays the use of very recent packages until they have existed long enough to be assessed. It is a practical anti-abuse measure against dependency staging, especially when attackers publish a malicious package shortly before a trusted release consumes it.
• Publisher Identity: The account or automation identity authorised to publish software artifacts to a registry. In modern supply chains, it is a security boundary because whoever controls the publisher can influence what downstream systems install, execute, and trust.

What's in the full analysis

Aikido's full article covers the operational detail this post intentionally leaves for the source:

• Exact package and filesystem indicators of compromise for macOS, Windows, and Linux hosts
• Step-by-step checks for package-lock files, installed dependencies, and hidden dropper directories
• Concrete remediation commands for pinning safe axios versions and removing the malicious dependency
• Safe Chain policy details for blocking newly published packages before they execute

👉 Aikido's full post covers the compromise timeline, indicators of compromise, and remediation steps

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, secrets management, and identity lifecycle controls. It helps practitioners align automation, release identity, and access assurance across modern security programmes.