Axios npm account takeover shows how token abuse bypasses CI trust

At a glance

What this is: A compromised npm maintainer account was used to publish malicious Axios releases that installed a cross-platform RAT through a hidden dependency and postinstall hook.

Why it matters: This matters because package registry access, token lifecycle, and CI provenance controls now sit on the same blast radius as source code integrity for build systems and developer endpoints.

By the numbers:

• Two malicious Axios versions 1.14.1 and 0.30.4 were live for roughly three hours before npm removed them.
• Axios has over 83 million weekly downloads, making the poisoned releases a high-reach supply chain event.

👉 Read LEGIT Security's analysis of the Axios npm account takeover and poisoned releases

Context

npm package compromise is a supply chain and identity problem as much as an application security problem. When a maintainer token is long-lived and broadly privileged, registry access can bypass source controls, CI provenance, and normal release review.

The Axios case shows how quickly a trusted JavaScript dependency can become an execution path on developer machines and CI runners. The identity angle is direct: a stolen non-human credential was the access mechanism, and the resulting blast radius extended into build environments, not just production code.

Key questions

Q: What breaks when a package registry token is stolen and used to publish malware?

A: A stolen registry token breaks the trust chain between source review and package publication. Attackers can publish directly from the registry account, bypass federated build controls, and reach developer or CI environments before anyone notices. The failure is not only access theft, but persistence through a high-privilege non-human identity that was never meant to live indefinitely.

Q: Why do long-lived NHI credentials increase supply-chain risk?

A: They increase supply-chain risk because build systems, package installs, and developer tools can harvest and reuse them without a separate exploit chain. A long-lived credential stays useful long after the initial exposure, which means one compromise can extend into cloud, CI/CD, and secrets infrastructure.

Q: How do security teams detect malicious npm postinstall behaviour?

A: Look for packages that define lifecycle hooks, then correlate installs with unexpected child processes, shell spawning, and outbound connections from build hosts. Detection should focus on behaviour during installation, not just signature matches on known malware. A package that looks empty can still be dangerous if it executes commands on install.

Q: Who is accountable when a trusted open-source package is used to deliver malware?

A: Accountability usually spans the package maintainer, the registry authentication model, the consuming organisation’s build controls, and the team that owns credential lifecycle. If a malicious release was published through a valid account, the key question is whether publishing identities were time-bound, recoverable, and constrained enough to limit misuse.

Technical breakdown

How a stolen npm token becomes a release pipeline bypass

npm publishing trust depends on the registry account, its access token, and any provenance binding behind the release workflow. If an attacker steals a long-lived classic token, they can publish directly through the npm CLI even when a project normally relies on GitHub Actions OIDC Trusted Publisher controls. Changing the maintainer email also blocks recovery and slows legitimate response. In this case, collaborator permissions were uneven, which further reduced containment speed.

Practical implication: treat registry tokens as high-value identities and remove any publication path that is not bound to short-lived, federated authentication.

Why a phantom dependency and postinstall hook are so effective

A phantom dependency is a package added to manifest files for execution rather than functionality. In this attack, the malicious dependency existed only to trigger a postinstall hook, which runs automatically during npm install. That means code execution happens before most teams inspect the package contents, and it can happen on developer laptops, CI runners, and build containers alike. Because the hook is attached to a transitive dependency, normal dependency review may miss it entirely.

Practical implication: block script execution by default in CI and inspect any new dependency that exists only to trigger install-time code.

How self-destructing malware defeats after-the-fact inspection

The dropper fetched platform-specific payloads, executed them, and then removed its own traces by deleting the malicious manifest and staging a clean replacement. That behaviour collapses the window for post-install forensics, because static inspection after execution tells you little about what actually ran. The attack also spread across macOS, Windows, and Linux, which broadens the detection challenge for organisations that assume build compromise is platform-specific.

Practical implication: prioritise runtime detection during installation and endpoint telemetry over relying on later file-system review alone.

Threat narrative

Attacker objective: The attacker aimed to gain persistent remote access to developer and CI environments so they could steal credentials, control hosts, and widen supply chain compromise.

1. Entry occurred when the attacker used a stolen classic npm access token to publish poisoned Axios releases directly to the registry.
2. Escalation happened when the malicious package introduced a phantom dependency and postinstall hook that executed a dropper on macOS, Windows, and Linux.
3. Impact followed as the dropper fetched a cross-platform RAT, erased traces, and exposed developer or CI environments to remote command execution and credential theft.

Breaches seen in the wild

• Vercel Context.ai OAuth Supply Chain Breach — Shadow AI app Context.ai OAuth integration exposes Vercel customer data via unmanaged third-party token.
• 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

Token lifetime is now a supply chain control problem, not just a registry hygiene issue. A long-lived npm token can bypass source review, CI provenance, and maintainer expectations in one step. That makes secret lifecycle governance part of software supply chain security, especially where registry credentials can publish production artifacts. Practitioner conclusion: bind publishing to short-lived federated identity wherever possible.

Phantom dependencies create a governance gap between what teams review and what actually executes. Security teams often review declared application dependencies but not dependencies added purely to trigger install-time code. The result is a blind spot where execution can start before any human or automated review sees the payload. Practitioner conclusion: review for execution intent, not just package presence.

Self-erasing payloads amplify the value of runtime controls over retrospective cleanup. When malware deletes its own staging files and swaps in a clean manifest, file-based after-action analysis loses much of its value. This shifts assurance toward install-time monitoring, endpoint telemetry, and registry event correlation. Practitioner conclusion: make runtime detection part of build security, not an afterthought.

Non-human identity governance and software supply chain governance are converging. The compromised npm token functioned as a non-human identity with excessive standing privilege, which is exactly the kind of access path NHI governance is meant to constrain. In environments where automation can publish code or trigger build steps, identity lifecycle, rotation, and recovery rules matter as much as code review. Practitioner conclusion: treat build credentials as governed identities.

Postinstall abuse is a named concept teams should now track explicitly. This pattern combines package installation with automatic script execution and turns dependency intake into an execution channel. It matters because the attack succeeds without exploiting a software bug in the target codebase. Practitioner conclusion: classify install-time execution as a distinct control domain in supply chain policy.

From our research:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• From our research: 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• From our research: The NHI breach pattern here aligns with 52 NHI Breaches Analysis, which maps how token abuse and overprivileged access turn trusted identities into attack paths.

What this signals

The broader signal is that software supply chain compromise increasingly starts with identity control failure, not with a software bug. When registry credentials, CI trust, and package execution are intertwined, the programme boundary shifts toward governed publishing identities and install-time monitoring.

Non-human identity drift: build tokens, release credentials, and automation accounts are now part of the same risk surface as service accounts and API keys. Teams that still separate developer tooling from identity governance will miss the path attackers actually use to turn a package into code execution.

For practitioners, the next control question is whether package publication, build execution, and host compromise are observable as one chain. If they are not, the programme has a detection gap that attackers can exploit in minutes rather than hours.

For practitioners

• Lock down registry publishing identities Replace long-lived classic npm tokens with short-lived, federated publishing identities and revoke any token that can still publish without OIDC binding. Keep registry access on a strict lifecycle with rotation, expiry, and recovery controls.
• Disable install-time scripts in CI Use --ignore-scripts or an equivalent policy for automated builds unless a package is explicitly approved for execution. Add exception handling for packages that need install hooks and monitor those exceptions tightly.
• Scan lockfiles for phantom dependencies Look for packages that do not belong in the dependency graph, especially names that exist only to execute a postinstall hook. Investigate any unexpected node_modules entries and verify they were not introduced for runtime code execution.
• Treat developer and runner hosts as compromised if affected If any machine or CI runner installed the poisoned release, assume host-level compromise, rebuild from clean images, and rotate every credential accessible from that environment, including cloud, registry, and source control secrets.
• Add network blocks for the known C2 indicators Block sfrclak[.]com and 142.11.206.73 at the network layer and search endpoint telemetry for the listed macOS, Windows, and Linux artifacts before returning systems to service.

Key takeaways

• This incident shows that a stolen package registry token can bypass provenance controls and turn a trusted dependency into a malware delivery path.
• The scale matters because Axios reaches over 83 million weekly downloads, while the malicious releases were live long enough to contaminate active installs across platforms.
• The control that matters most is short-lived, federated publishing identity paired with install-time script blocking and runtime detection on build hosts.

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.
• 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.
• Registry Publishing Identity: A registry publishing identity is the account, token, or federated credential allowed to release software artifacts to a package ecosystem. When it is long-lived or overly broad, it becomes a high-value non-human identity that can be abused to poison trusted releases.
• Provenance Bypass: A provenance bypass occurs when an attacker publishes or delivers software through a path that sidesteps the intended source-of-truth controls. It weakens assurance because downstream consumers see a valid package name, not the trust failure behind it.

What's in the full analysis

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

• The exact package versions, hashes, and exposure windows that help teams validate whether their lockfiles were touched.
• The malicious file paths and platform-specific payload artefacts that support endpoint hunting on macOS, Windows, and Linux.
• The attacker workflow around email takeover, publishing history, and direct npm CLI use that explains how registry trust was bypassed.
• The specific remediation playbooks and indicators of compromise that the article says teams can drop into their response workflow.

👉 The full LEGIT Security article includes hashes, artefacts, and remediation steps for affected teams.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners build controls that fit modern identity and access programmes across engineering and security teams.