Axios npm Compromised: 100M-Download Library Used to Deploy RAT via Maintainer Account Hijack

On March 31, 2026, attackers hijacked the npm account of jasonsaayman, the lead maintainer of axios, and published two malicious package versions containing a cross-platform remote access trojan. Axios has over 100 million weekly downloads. It is one of the most widely depended-upon JavaScript libraries ever written.

This is not a theoretical supply chain risk. This is a confirmed, active incident targeting the JavaScript ecosystem at its widest point. If you or your CI pipeline ran npm install axios on March 31 before the packages were removed, you need to act now.

“One compromised maintainer account. One hundred million potential install targets. No verification step in between.”

Check Your Environment Right Now

npm list axios

# Remove and reinstall a safe version
npm uninstall axios
npm install axios@1.7.9

# Clear npm cache
npm cache clean --force

Indicators of Compromise

These are the technical indicators published by researchers. Use them for log review, EDR queries, and network blocking:

How the Attack Worked

The attack unfolded in three hours. It is methodical, and every step exploited a gap that the npm ecosystem has no automated control for.

First, at 23:59 UTC on March 30, the attacker account nrwise published a new package called plain-crypto-js@4.2.1 to npm. This package had never existed before. It contained a postinstall hook , a script that runs automatically when the package is installed , that dropped a platform-specific RAT payload and called home to sfrclak[.]com:8000.

Then the attackers used the compromised jasonsaayman account to publish two new axios versions , 1.14.1 at 00:21 UTC and 0.30.4 at 01:00 UTC , each adding plain-crypto-js as a dependency. Since axios is a direct dependency for tens of millions of projects, any developer or CI pipeline that ran npm install in that two-hour window pulled the malicious package automatically with no warning and no prompt.

Timeline

This Is Not New. The Scale Is.

Maintainer account takeovers and poisoned dependencies are not a new class of attack. But the targets are getting bigger. The axios compromise joins a long line of high-impact supply chain incidents, each one exploiting the same structural gap: package registries accept uploads from any authenticated account, and nobody automatically verifies that the package contents are consistent with the project's known behaviour.

“The LiteLLM attack and the axios attack happened one week apart. Different registries. Same playbook: account compromise, malicious dependency, postinstall hook, self-deleting payload. The ecosystem has not learned from this pattern because there is no automated mechanism to detect it.”

Why npm Cannot Catch This

When jasonsaayman's account published axios@1.14.1, it was a cryptographically valid, authenticated publish by the account that owns the package. From npm's perspective, there was nothing anomalous about it.

That is the structural problem. npm authenticates the publisher. It does not verify that what was published is consistent with what that publisher has always published. It does not check whether a dependency that has never appeared in axios was just added. It does not scan postinstall scripts for network callbacks to unknown infrastructure. It trusts the token, not the content.

How Helixar ReleaseGuard Catches This Class of Attack

Helixar ReleaseGuard is an open-source artifact policy engine that scans software releases before they are distributed and flags anomalies that indicate supply chain compromise. It is available free on GitHub and the GitHub Marketplace, requires no account for core functionality, and takes under five minutes to integrate into a CI pipeline.

The axios attack had three detectable signals , all of which ReleaseGuard would have flagged at publish time:

Critically, ReleaseGuard can be run on the consuming side too, not just by the publisher. If your CI pipeline scans the npm tarball of any new dependency version before it is installed, you would have blocked plain-crypto-js@4.2.1 before it ever executed on your systems. This is the defence-in-depth posture that the industry needs to normalise.

What Every Team Should Do Before the Next Incident

The axios attack and the LiteLLM attack one week earlier make the same point: your CI pipeline is pulling packages from registries that do not verify content, and you are probably not verifying it either. Here is a baseline every team should have in place.

The Broader Picture: Developer Tools Under Attack

Axios is not an AI library. It is a general-purpose HTTP client used across the entire JavaScript ecosystem. The targeting logic here is straightforward: attack the tool that every developer uses, not the tool that some developers use.

But the pattern is accelerating specifically in the AI development toolchain. In the last month alone we have documented the LiteLLM PyPI attack targeting AI developers, the Qihoo 360 SSL key exposure in a public AI product installer, and now the axios compromise. The tools used to build AI applications are being targeted deliberately, because the developers of AI applications are high-value targets: they have access to cloud infrastructure, LLM API keys, proprietary datasets, and production deployment credentials.

If you are building in the AI space and have not thought carefully about your supply chain posture, the attackers have already thought about it for you.