The Axios Supply Chain Attack: What You Need to Know (and Do) Right Now

On March 31, 2026, the JavaScript ecosystem woke up to every developer's nightmare. Axios, the ubiquitous HTTP client with over 100 million weekly downloads, was compromised.

This wasn't a bug in the code. It was a sophisticated supply chain attack that turned a trusted tool into a delivery vehicle for malware. If you ran npm install or yarn during a specific 3-hour window on Tuesday, your machine — or your CI/CD pipeline — might be compromised.

Here is the breakdown of what happened and the steps you must take to secure your systems.

---

The TL;DR (Action Required)

If you are using Axios, check your package-lock.json or yarn.lock immediately.

• Affected Versions: 1.14.1 and 0.30.4
• Safe Versions: Downgrade to 1.14.0 or 0.30.3
• The Red Flag: Look for a dependency called plain-crypto-js in your lockfile or node_modules

---

How the Attack Unfolded

The attack was a Maintainer Takeover. An attacker (identified by security researchers as a North Korean-linked group) gained access to the NPM account of a lead Axios maintainer.

The "Phantom Dependency" Strategy

Instead of modifying the Axios source code — which might have been caught by automated PR reviews — the attacker simply updated package.json to include a new dependency: plain-crypto-js@4.2.1.

This package was a "dropper." It didn't actually do any crypto work. Instead, it used a postinstall hook to execute a script called setup.js the moment you downloaded the package.

Multi-Platform Malware

The setup.js script was surprisingly sophisticated. It identified the host OS and deployed a tailored Remote Access Trojan (RAT) for each platform:

• Windows: Established persistence via registry keys
• macOS: Used osascript to trigger background processes
• Linux: Dropped a Python-based implant in /tmp

The "Ghost" Cleanup

To make things harder for forensic teams, the malware was designed to self-destruct. After the RAT was successfully launched, the script:

1. Deleted its own setup.js file
2. Rewrote package.json to remove the malicious dependency
3. Attempted to leave the environment looking exactly as it did before the install

---

How to Check if You're Affected

Run this command in your project terminal to see if the malicious dependency ever touched your disk:

find node_modules -name "plain-crypto-js" -type d

Then check your lockfile for the specific poisoned versions:

grep -E "1.14.1|0.30.4" package-lock.json

---

Immediate Remediation Steps

If you find evidence of the compromise, do not just delete the folder. Assume the environment is "dirty."

1. Revert and Pin

Force your project to use the last known safe version. Update your package.json:

"dependencies": {
  "axios": "1.14.0"
}

Note: Avoid using the caret ^ for now to prevent accidental upgrades back to the poisoned versions if they still exist in your private mirrors.

2. Rotate ALL Secrets

The primary goal of this RAT was credential theft. If the malicious version ran in your CI/CD or on your local machine, you must rotate:

• NPM / GitHub Tokens
• AWS / Azure / GCP Access Keys
• Database connection strings
• SSH Keys

3. Clear Your Caches

The malicious metadata might still be in your local or shared build cache:

npm cache clean --force

---

Lessons for the Future

This incident highlights a major gap in the JS ecosystem: post-install scripts are dangerous.

Going forward, consider adopting these practices:

Use --ignore-scripts in CI/CD
Run npm install --ignore-scripts to prevent third-party code from executing during the build process.

Pin your dependencies
Use exact version numbers rather than ranges (^ or ~) for mission-critical libraries. Ranges are convenient until they aren't.

Monitor with Socket or Snyk
These tools flag suspicious changes to popular packages — including first-time or unexpected dependencies being added. The signal-to-noise ratio is worth it.

---

Stay safe out there. The convenience of open source comes with the responsibility of constant vigilance.