Supply ChainResearch

400 Million Downloads a Month and Nobody Was Watching: The Axios npm Compromise

Hackers hijacked the lead maintainer account of Axios, the most popular JavaScript HTTP client, and pushed malicious versions that deployed cross-platform RATs. The attack was live for three hours.

TL;DR

On March 31, 2026, attackers compromised the npm account of the lead Axios maintainer and published two malicious versions that deploy a remote access trojan on macOS, Windows, and Linux. The attack was live for approximately three hours. If your environment pulled either version during that window, assume full compromise and rebuild.

The biggest JavaScript package you depend on just got owned

Axios has over 400 million monthly downloads. It is the most popular HTTP client in the JavaScript ecosystem – used by startups, enterprises, and everything in between. If your engineering team builds anything that talks to an API, there is a very good chance Axios is somewhere in the dependency tree.

The entire attack came down to a single line added to the package manifest. One phantom dependency – a package called plain-crypto-js that is never imported, never referenced, and never used anywhere in the Axios source code. It exists solely to trigger an install hook that runs a dropper. No other file was modified. The source code is identical to the clean release. A developer reviewing the diff would see nothing suspicious.

If you have been following my coverage of supply chain attacks, this should look familiar. One week ago, the litellm Python package was compromised using the same playbook – hijacked maintainer account, malicious code injected outside the main source, blast radius in the hundreds of millions. The registries change. The languages change. The attack surface stays the same.

This was planned, not opportunistic

StepSecurity called this “among the most operationally sophisticated supply chain attacks ever documented against a top-10 npm package.”

The attacker staged the operation across 18 hours. First, they published a clean decoy version of the malicious dependency to build publishing history on npm – a counter-intelligence move designed to avoid triggering “brand-new package” alarms from security scanners. They registered C2 infrastructure through two different domain registrars pointing to the same server. Then, within 39 minutes, they poisoned both the modern 1.x and legacy 0.x release branches of Axios, maximising coverage across the entire user base.

On the 1.x side, any project using a standard caret range would automatically pull the compromised version on its next install. The 0.x exposure was narrower due to how npm handles semver for pre-1.0 packages, but both branches were hit deliberately.

The malicious versions were live for approximately three hours before npm’s security team intervened. For a package of this popularity, that is an eternity.

The security mechanism was there – it just was not enforced

Axios was already using npm’s OIDC Trusted Publisher mechanism – a system that cryptographically ties every publish to a verified GitHub Actions workflow. Every legitimate Axios release carries this provenance signature. The malicious versions did not. They were published manually with a stolen access token, completely bypassing the OIDC pipeline.

The security mechanism was in place and working. But the maintainer’s account still had a classic long-lived npm token that could publish directly. The OIDC pipeline was an option, not a requirement. The attacker walked through the door that was supposed to be locked but never was.

Every open source project that has adopted trusted publishing but has not revoked legacy access tokens is carrying the same risk. The security posture looks good on paper until someone tests the one path you forgot to close.

The governance gap nobody talks about

When the attack was discovered, the Axios team could not fix it themselves. A collaborator publicly stated they could not revoke the compromised account’s publishing access because the attacker’s permissions exceeded their own. The project had to wait for npm’s security team to step in.

One of the most depended-on packages in the JavaScript ecosystem had a single point of failure in its maintainer hierarchy, and when that point failed, no one else on the team had the authority to respond. Pure governance failure. And it is endemic across open source.

If your organisation depends on open source packages – and it does – ask yourself: how many of those projects have a bus factor of one? How many have a succession plan for compromised credentials? The answer, for most of the ecosystem, is zero.

The malware was built to disappear

The RAT delivered platform-specific payloads for macOS, Windows, and Linux. Each variant was tailored to its target – using native tools, native persistence mechanisms, and file paths designed to blend in with legitimate system processes. The Windows variant achieved fileless persistence that survives reboots. The macOS variant disguised itself as an Apple system daemon. The C2 traffic was crafted to look like routine npm registry communication in network logs.

After execution, the dropper deleted itself and replaced its own package manifest with a clean version. Post-infection, the installed directory looks completely normal. Running standard package auditing tools would not flag anything. An incident responder checking node_modules after the fact would find no trace of the attack.

The self-destruct was not an afterthought. The replacement manifest even reports a different version number than the one that was actually installed – meaning automated scans for the known-malicious version produce false negatives. The only reliable indicator is the presence of the plain-crypto-js directory itself, which has no business existing in any legitimate Axios installation.

What to do right now

If you installed axios@1.14.1 or axios@0.30.4 during the exposure window (March 31, 00:21–03:15 UTC):

  • Do not attempt to clean in place. Rebuild from a known-good image
  • Rotate every credential accessible on the affected system – npm tokens, SSH keys, cloud provider credentials, CI/CD secrets, database passwords
  • Audit CI/CD pipeline logs for any runs that installed the affected versions and rotate all injected secrets
  • Block sfrclak.com, callnrwise.com, and 142.11.206.73 at the network and DNS layer

For everyone else:

  • Pin your dependencies. Use npm ci with committed lockfiles, not npm install
  • Run npm ci --ignore-scripts in CI/CD as standing policy
  • Set a minimum release age (npm config set min-release-age 3) to block packages published less than three days ago
  • Monitor npm provenance metadata. A package that has always published via OIDC suddenly publishing without it is a compromise signal
  • Audit your dependency tree for phantom dependencies – packages in the manifest that are never imported in the codebase

Nobody learned anything last time

The attacker behind the Axios compromise has not been identified. Security researchers confirmed it does not match the TeamPCP campaigns responsible for the recent Telnyx and Trivy attacks. The C2 infrastructure is offline.

But the playbook is not new. We saw the same pattern with litellm a week ago. We will see it again next month. The fundamental vulnerability is structural. We built a global software ecosystem on top of packages maintained by individuals with single-factor publishing authority and no succession planning. Every time one of these attacks lands, the industry acts surprised, rotates some credentials, and changes nothing about the underlying trust model.

npm’s OIDC Trusted Publisher exists. Lockfiles exist. Release age policies exist. The tools are there. Your organisation will either enforce them before the next maintainer account gets popped, or you will keep running npm install with your fingers crossed. Place your bets.

Sources

← All posts