What Happened

On March 31, 2026, two malicious versions of axios were published to npm: 1.14.1 and 0.30.4. Axios gets downloaded somewhere between 100 and 300 million times a week, making it one of the most widely used packages in the JavaScript ecosystem.

An attacker hijacked the npm credentials of a lead maintainer, changed the account email to an anonymous ProtonMail address, and manually published both versions outside the normal release workflow. Neither version appears in axios’s GitHub tags, and neither went through CI/CD.

The attack was operationally deliberate. The fake dependency plain-crypto-js@4.2.1 was staged roughly 18 hours before the malicious axios versions went live. Both release branches were hit within 39 minutes of each other.

How the Malware Works

The axios packages themselves contain no malicious code. Instead, they pull in plain-crypto-js as a dependency. That package runs a postinstall script that downloads and executes platform-specific second-stage payloads from a C2 server at sfrclak.com:8000, targeting macOS, Windows, and Linux.

After execution, the payload self-deletes and overwrites its own package.json with a clean stub, making forensic detection harder.

Any system that ran npm install after 2026-03-31T00:21:58Z without a lockfile pinning a prior safe version may be compromised.

Socket’s automated detection flagged the malicious package within minutes. Vercel blocked outbound access to the C2 hostname, and the malicious versions have since been unpublished from npm.

What to Do Now

Check If You’re Affected

Search your lockfiles and node_modules for any trace of the malicious packages:

# Check for malicious axios versions
grep -r "axios@1\.14\.1\|axios@0\.30\.4" package-lock.json yarn.lock pnpm-lock.yaml

# Check for the malicious dependency
grep -r "plain-crypto-js" node_modules package-lock.json yarn.lock pnpm-lock.yaml

Also check your network logs for any outbound connections to sfrclak.com.

Remediate

1. Pin to a safe version — use axios@1.14.0 or axios@0.30.3
2. Rotate all secrets — any API keys, SSH keys, tokens, or credentials present in affected build environments should be considered compromised and rotated immediately
3. Redeploy affected projects from a clean environment
4. Add --ignore-scripts to CI npm installs going forward:

npm ci --ignore-scripts

The Broader Problem

Andrej Karpathy noted that he had axios pulled in transitively through a Google Workspace CLI tool he’d been experimenting with. The installed version happened to resolve to an unaffected 1.13.5, but the dependency wasn’t pinned — if he’d run the install a few hours later, it would have resolved to latest and pulled the malicious version.

That’s the uncomfortable reality here. One compromised maintainer account, a package that’s installed hundreds of millions of times a week, and the attack surface is enormous. Pinning dependencies and using lockfiles helps individually, but the defaults of package managers like npm and pip don’t protect users who aren’t already thinking carefully about this. A single infection — usually caught fairly quickly by security scanners — can still spread widely before it’s pulled.

Further Reading

• axios supply chain attack — what happened and what to do (devops-daily.com)
• axios compromised on npm — malicious versions drop remote access trojan (stepsecurity.io)

If you found this post helpful, consider buying me a coffee. It keeps me writing!