The Axios Supply Chain Attack — What Happened and How to Prevent It

On March 30, 2026, an attacker compromised the npm account of jasonsaayman — the lead maintainer of the axios project — and changed the registered email to an attacker-controlled Proton Mail address. Within hours, they published two backdoored versions that injected a phantom dependency called plain-crypto-js@4.2.1. StepSecurity's research team was first to identify and report the compromise.

This dependency is never imported anywhere in the axios source code. Its sole purpose is to execute a postinstall script that acts as a cross-platform RAT dropper. The payload targets macOS, Windows, and Linux with separate binaries — each pre-built and staged 18 hours before the attack went live. Socket's deep-dive analysis found additional packages distributing the same malware through vendored dependencies.

The dropper uses two layers of obfuscation — reversed Base64 encoding with padding character substitution and XOR cipher with the key OrDeR_7077. After execution, the malware deletes itself and replaces its own package.json with a clean version to evade forensic detection. Every trace was designed to self-destruct. Snyk has a detailed technical breakdown of the full payload chain.

Most teams I talk to had the same initial reaction: “We don't use axios.” And they're wrong. Axios is a transitive dependency for thousands of packages. As The Hacker News reported, this is “potentially one of the largest in npm history” by blast radius. Your project might not list it in package.json, but there's a good chance something in your node_modules depends on it.

Run npm ls axios in any non-trivial Node.js project. You'll likely see it appear multiple times through packages you never associated with HTTP clients.

Three lines in a .npmrc file at the root of your project. That's the difference between “compromised” and “not my problem.” Commit this file to your repo so every developer and CI runner inherits the same policy.

The min-release-age=7 setting is the single most impactful line. Introduced in npm v11.10.0 (February 2026), it tells npm to refuse any package version published less than n days ago. The value is in days — 7 means one week. The axios attack was detected and pulled within 2-3 hours. A 7-day delay means you never would have installed it. You can read the original implementation PR for technical details. Note that there's a known bug with tilde (~) version ranges — another reason to use save-exact=true.

If you also use Dependabot for version updates, you can align its cooldown settings with your min-release-age so both your local installs and your automated PRs respect the same waiting period. pnpm and Yarn have had similar features since late 2025 — Andrew Nesbitt wrote a great overview of the ecosystem-wide shift toward release-age gating.

Disabling scripts blocks the primary malware execution vector. The axios RAT ran entirely through a postinstall script in plain-crypto-js. With ignore-scripts=true, that script never executes. Some legitimate packages need postinstall scripts (sharp, esbuild, prisma) — allowlist those explicitly:

And save-exact=true means npm install axios writes "axios": "1.14.0" instead of "axios": "^1.14.0". No caret, no surprise resolutions. Every version bump becomes a pull request you actually review.

I need to say this clearly because I've watched it happen too many times: your package-lock.json is not a build artifact. It's a security contract. The pnpm team calls it “part of your supply chain contract” — and they're right. It pins every resolved version — direct and transitive — to exact hashes. When your lockfile says axios@1.13.6, that's exactly what gets installed. No surprises. No “helpful” upgrades.

Here's the scenario that keeps me up at night: a developer hits a merge conflict in package-lock.json. It's 4,000 lines of JSON diff. They don't want to deal with it. So they delete the lockfile, run npm install, get a fresh one, push, and move on. Problem solved, right?

Wrong. That fresh npm install resolves every ^ range to the latest matching version. If you did that during the 2-3 hour window when axios@1.14.1 was tagged latest, congratulations — you just installed a RAT on your machine and committed its hash into your repo for every other developer and CI runner to pick up.

There's an anxiety in our industry around staying current. Dependabot opens a PR, you merge it without reading the diff, and you feel responsible. “Latest” is not always “safest.” Sometimes the most secure thing you can do is not update.

The axios attack exploited exactly this instinct. The malicious version was tagged latest. Anyone who blindly ran npm update or had Dependabot set to auto-merge got burned. The developers who were “behind” on their axios version? They were fine.

A sane update strategy