<h2>What happened</h2>
On March 31, 2026, two malicious versions of axios were published to npm: <code>1.14.1</code> and <code>0.30.4</code>. 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 <code>plain-crypto-js@4.2.1</code> was staged roughly 18 hours before the malicious axios versions went live. Both release branches were hit within 39 minutes of each other.
<h2>How the malware works</h2>
The axios packages themselves contain no malicious code. Instead, they pull in <code>plain-crypto-js</code> as a dependency. That package runs a postinstall script that downloads and executes platform-specific second-stage payloads from a C2 server at <code>sfrclak.com:8000</code>, targeting macOS, Windows, and Linux.
After execution, the payload self-deletes and overwrites its own <code>package.json</code> with a clean stub, making forensic detection harder. Any system that ran <code>npm install</code> after <code>2026-03-31T00:21:58Z</code> 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.
<h2>What to do now</h2>
Check if you’re affected:
<ul>
<li>Search your lockfiles and <code>node_modules</code> for <code>axios@1.14.1</code>, <code>axios@0.30.4</code>, or any trace of <code>plain-crypto-js</code></li>
<li>Check network logs for connections to <code>sfrclak.com</code></li>
</ul>
Remediate:
<ul>
<li>Pin to <code>axios@1.14.0</code> or <code>axios@0.30.3</code></li>
<li>Rotate all secrets, API keys, SSH keys, and credentials present in any affected build environment</li>
<li>Redeploy affected projects</li>
<li>Add <code>--ignore-scripts</code> to CI npm installs going forward</li>
</ul>
<h2>The broader problem</h2>
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 <code>1.13.5</code>, but the dependency wasn’t pinned - if he’d run the install a few hours later, it would have resolved to <code>latest</code> 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.

Collections

Two malicious versions of axios (1.14.1 and 0.30.4) were published to npm on March 31, 2026, after an attacker hijacked a lead maintainer's npm credentials. The packages themselves were clean but pulled in a staged dependency, plain-crypto-js, which ran a postinstall script downloading platform-specific second-stage payloads from a C2 server. The payloads self-deleted after execution to hinder forensics. Socket detected the attack within minutes, Vercel blocked the C2 domain, and the versions were unpublished. Developers should check lockfiles and node_modules for the affected versions, rotate all secrets from affected environments, pin to safe versions, and add --ignore-scripts to CI npm installs. The incident highlights the systemic risk of unpinned dependencies in ecosystems where a single compromised maintainer account can affect hundreds of millions of weekly installs.

Malicious axios versions 1.14.1 and 0.30.4 deploy a remote access trojan via supply chain attack

The compromised version has already been removed from npm. npm’s response was very quick, with an exposure time of approximately 3 hours.
Congratulations to the npm team. 🥳

For europeans working 9to5 its pretty unlikely that their personal dev machines are affected because it was available only at midnight.

The attacks keep coming! Every time I read on of these I clinch up 😓 never know if you’re going to get hit.
Somebody definitely needs to do something about these.

This is really scary because it shows how much we trust packages we use every day without even thinking about it. Most developers probably don’t even think about Axios because it’s so common. That’s what made this attack so dangerous.
What struck me the most was how well-planned this was. The attackers didn’t even have to change Axios itself; they just added a dependency that most people wouldn’t notice. It shows that even a small update to a package can have a big effect when it is used in a lot of projects.
I also think this shows that depending on the newest versions without lockfiles or pinned dependencies is more dangerous than ever. Most developers are not constantly checking release tags, CI pipelines, or unusual dependencies during installs, especially for libraries they already trust. This attack is a strong reminder that secure defaults should be built into package managers because one compromised maintainer account can affect a huge part of the ecosystem very quickly.

I feel this gonna happen more and more