The Axios npm Attack: How a Social Engineering Campaign Compromised 100 Million Weekly Downloads
Written by the Rafter Team
On March 31, 2026, two backdoored versions of the axios npm package were published to the public registry. Axios is one of the most widely used JavaScript libraries — an HTTP client that handles web requests in millions of applications, downloaded over 100 million times per week.
The attack wasn't a technical exploit. It was a social engineering campaign. And for about three hours, every developer who ran npm install and pulled the latest axios unknowingly installed malware.
If you installed or updated npm packages on March 31, 2026, check your projects for plain-crypto-js in node_modules. If it's present, treat the machine as compromised: rotate all credentials, revoke API tokens, and review recent code changes.
What Happened
A North Korean state-backed hacking group — tracked by Microsoft as "Sapphire Sleet" and by Google as "UNC1069" — targeted the lead maintainer of the axios package. (Different security companies track the same groups under different names, which is why you'll see both labels in reporting about this incident.)
The attacker approached the maintainer by posing as the founder of a legitimate, well-known company. Through this social engineering, they eventually gained access to the maintainer's npm account and changed its registered email to an address they controlled.
From there, they published two compromised versions: axios@1.14.1 and axios@0.30.4, covering both active release lines. The malicious versions went live at approximately 00:21 UTC on March 31 and were removed around 03:15 UTC — a window of roughly three hours.
How the Attack Worked
The clever part of this attack is that the attacker didn't change the axios source code at all. If you looked at the code diff, axios looked normal. Instead, they added a new dependency to the package: plain-crypto-js@4.2.1.
This package had been quietly registered the day before — first a clean "decoy" version (4.2.0) to establish a publishing history, then the malicious version (4.2.1) roughly 18 hours later. By the time it was added to axios, it looked like an ordinary package with a version history.
The Payload
When npm installed plain-crypto-js, it ran a postinstall script — a piece of code that executes automatically after a package is installed. This script detected the developer's operating system and downloaded a matching piece of malware:
- On Mac, Windows, and Linux: The script dropped a remote access trojan (RAT) — essentially a program that gives the attacker remote control of the machine.
The malware could execute commands, read files, access environment variables (which often contain API keys and credentials), and establish persistence so it would survive reboots.
For any developer whose machine was affected, the attacker had the same access as the developer: files, credentials, cloud accounts, internal repositories — everything.
Why This Matters for AI Coding Tools
Supply chain attacks aren't new. The JavaScript ecosystem has seen similar incidents before — event-stream in 2018, ua-parser-js in 2021. But the landscape has changed.
AI coding tools — Claude Code, Codex CLI, and others — are built on npm packages. As the Claude Code source leak on the same day demonstrated, axios is in fact part of their dependency tree. They're also qualitatively different from most npm consumers because of the access they have:
- They can read and write files across your entire project
- They can execute terminal commands
- They often have access to environment variables containing credentials
- They work on developer machines, not in sandboxed production environments
When a library used by a web app is compromised, the impact is bounded by what that app can access. When a library used by an AI coding tool is compromised, the impact extends to everything the developer can access. That's a much larger blast radius.
The axios attack didn't specifically target AI coding tools. But it affected everyone who uses axios, and many of these tools depend on it either directly or through their dependency tree.
What to Do
Check If You Were Affected
- Search your
node_modulesdirectories forplain-crypto-js. If it's present, the machine was compromised. - Check your lockfiles for axios versions
1.14.1or0.30.4. - If affected: change all passwords, rotate API keys and tokens, review recent git commits for unauthorized changes, and consider reimaging the machine.
Prevent Future Supply Chain Issues
-
Use lockfiles and pin dependencies. Lockfiles (
package-lock.json,yarn.lock) ensure you get exactly the versions you've tested. Without them,npm installcan pull in new versions — including compromised ones — without you knowing. -
Review dependency changes in pull requests. The axios attack added a new dependency to
package.json. If your team reviews dependency changes as part of code review, this would have been visible. -
Run dependency scans regularly. A tool like Rafter's Fast Scan can check your project for known supply chain compromises and vulnerable dependencies in under a minute. Running it as part of your CI pipeline means issues are caught before code is merged.
-
Minimize your dependency surface. Fewer dependencies means fewer things that can go wrong. For AI coding tools specifically, prefer standalone installers over npm when available — Anthropic, for example, has deprecated npm installation for Claude Code in favor of a standalone binary.
-
Monitor for unusual dependency behavior. Watch for new transitive dependencies, changes to postinstall scripts, and maintainer account changes. These are the early warning signs of a supply chain compromise.
The Bigger Picture
The npm ecosystem processes billions of package downloads every week, and the vast majority of that works as intended. But the trust model depends heavily on individual maintainer accounts being secure. This attack showed that a single social engineering success — one person tricked into handing over access — can ripple through millions of downstream projects.
The attack was detected and contained in three hours. That's relatively fast. But in those three hours, an unknown number of developers installed malware on their machines. Some of them may not have noticed yet.
There's no way to eliminate this risk entirely. But a combination of dependency pinning, regular scanning, careful code review, and awareness of what's changing in your dependency tree makes a meaningful difference. The goal isn't perfect security — it's raising the bar high enough that attacks like this get caught before they cause serious damage.