Axios Just Got Hacked. Here's What You Need to Know.
Axios Just Got Hacked. Here's What You Need to Know.
If you're a Node.js developer, stop what you're doing and check your package.json.
Today — March 31, 2026 — Axios, one of the most used HTTP libraries in the JavaScript ecosystem, was compromised in a supply chain attack. Not a theoretical vulnerability. Not a minor CVE. A real backdoor that was live on npm, actively installing remote access trojans on developer machines.
I've been using Axios in almost every backend project I've worked on. When I saw this news, the first thing I did was check every project I maintain. If you haven't done the same yet, do it now. I'll wait.
What Happened
An attacker compromised the GitHub and npm accounts of Axios's main maintainer. They changed the account email to lock out the original owner, then published two backdoored versions to npm: axios@1.14.1 and axios@0.30.4.
These versions included a malicious dependency called plain-crypto-js@4.2.1 — a trojanized copy of the legitimate crypto-js library. The moment you ran npm install, a hidden postinstall script executed automatically. It contacted a command-and-control server, downloaded platform-specific malware for macOS, Windows, or Linux, and then erased itself. It even replaced its own package.json with a clean version so if you inspected your node_modules after the fact, everything looked normal.
The entire compromise took roughly 15 seconds from install to full infection.
The backdoored packages were live for about 2–3 hours before being taken down. That might sound short, but Axios gets around 100 million downloads per week and sits in roughly 80% of cloud and code environments. Researchers observed execution in 3% of affected environments during that window alone.
Are You Affected?
Check right now. Here's how:
1. Check your Axios version:
npm ls axios
If you see 1.14.1 or 0.30.4, you're affected.
2. Check for the malicious dependency:
ls node_modules/plain-crypto-js
If that folder exists, the dropper already ran on your machine.
3. Check for the RAT (Remote Access Trojan):
- macOS:
/Library/Caches/com.apple.act.mond - Windows:
%PROGRAMDATA%\wt.exe - Linux:
/tmp/ld.py
If any of these files exist on your system, your machine is fully compromised. Don't try to clean it. Rebuild from scratch.
What to Do Right Now
If you installed the affected versions:
- Disconnect the machine from the network immediately.
- Rotate every credential the machine had access to — npm tokens, AWS keys, SSH keys, cloud credentials, CI/CD secrets, database passwords, and anything stored in
.envfiles. - Rebuild from a clean state. A compromised machine cannot be trusted again.
- Audit your CI/CD pipelines. If any automated build ran
npm installduring the attack window, those environments need the same treatment.
If you're on a clean version:
-
Pin Axios to
1.14.0(or0.30.3for the 0.x branch). -
Add an overrides block in your
package.json:
{
"overrides": {
"axios": "1.14.0"
}
}
-
Remove
plain-crypto-jsif it exists anywhere in yournode_modules. -
Block the known C2 infrastructure at the network/firewall level — IP
142.11.206.73and domainsfrclak.com.
How to Protect Yourself From Attacks Like This in the Future
This attack wasn't sophisticated from a technical standpoint. It was effective because developers trust their dependencies blindly. Here's how to make sure you're not caught off guard next time.
1. Lock and Pin Your Dependencies
Always commit your package-lock.json or yarn.lock. These files ensure that every install resolves to the exact same versions. Without them, a minor version bump — like 1.14.0 to 1.14.1 — gets pulled automatically and silently.
For critical packages, pin exact versions in your package.json:
{
"dependencies": {
"axios": "1.14.0"
}
}
No caret (^), no tilde (~). Exact version. You update when you decide, not when npm decides.
2. Disable Postinstall Scripts in CI/CD
Most legitimate packages don't need postinstall scripts. This attack relied entirely on one. You can disable them in your build pipelines:
npm install --ignore-scripts
If a specific package genuinely needs a postinstall step (like sharp or bcrypt), you can allowlist it explicitly. But the default should be to block them.
3. Use npm audit Regularly
Make it part of your workflow. Run it locally and in CI:
npm audit
It won't catch zero-day supply chain attacks in real time, but it surfaces known vulnerabilities quickly and keeps you aware of your dependency health.
4. Enable 2FA on Your npm Account
This attack started because a maintainer's account was compromised. If you publish any packages — even internal ones — enable two-factor authentication on npm. It takes two minutes and prevents the most common account takeover vector.
5. Monitor Your Dependencies With Automated Tools
Tools like Socket.dev, Snyk, and npm's built-in provenance checks can flag suspicious behavior in packages — new postinstall scripts, obfuscated code, unexpected network calls, or sudden maintainer changes. Integrate them into your CI pipeline so you get alerts before compromised code reaches production.
6. Treat Your CI/CD Pipeline as an Attack Surface
Your build environment has access to secrets, deployment keys, and production infrastructure. A compromised dependency running in CI is often more dangerous than on a developer laptop. Apply the principle of least privilege: CI runners should only have access to the credentials they absolutely need, and secrets should be scoped per job, not globally available.
7. Review Dependency Updates Before Merging
Don't auto-merge Dependabot or Renovate PRs for non-patch updates without reviewing changelogs. If a package you depend on suddenly changes maintainers, adds new dependencies, or introduces postinstall scripts — that's worth investigating before you pull it in.
8. Have an Incident Response Plan
When something like this happens, speed matters. Know in advance:
- How to check which version of a package is deployed across your projects
- How to rotate credentials quickly
- Who on your team is responsible for dependency security
- How to communicate the issue to stakeholders
If you're scrambling to figure this out during an incident, you've already lost time.
Final Thought
Axios has been a staple in almost every Node.js project for years. That level of trust is exactly what makes supply chain attacks so effective. The packages we npm install without a second thought are maintained by individuals, and individual accounts can be compromised.
This won't be the last attack like this. The JavaScript ecosystem's greatest strength — a massive, open package registry — is also its biggest vulnerability. The only thing you can control is how prepared you are when it happens.
Stay vigilant. Pin your versions. Check your lockfiles. And go verify your Axios version right now.
If this post helped you, share it with your team. The more developers who know about this, the smaller the blast radius.