Axios RAT Attack: What Happened and How to Check

Yesterday, the JavaScript ecosystem experienced one of its most sophisticated security breaches to date. Two malicious versions of Axios—a library with over 100 million weekly downloads—were published to npm containing a remote access trojan (RAT). If that sentence made your stomach drop, you're not alone.

What makes this attack particularly unsettling isn't just its scale—it's the precision. This wasn't someone copy-pasting a crypto miner into the source code like it's 2015. The attacker understood how modern JavaScript infrastructure works, then weaponized that knowledge.

How the Attack Actually Worked

Here's the thing that's keeping me up: Axios itself contains exactly zero malicious code. The source code is clean. Your code reviews would have found nothing.

Instead, the attacker added a seemingly innocuous dependency called plain-crypto-js to the malicious Axios releases. This package looks almost identical to the legitimate crypto-js library—the kind of typosquat that your brain automatically corrects when scanning a package.json.

That dependency contained a post-install script. If you're not familiar, post-install scripts run automatically when you npm install a package. They're legitimate features used for building native modules or setting up project configurations. They're also a known attack vector that the community has been worried about for years.

Step Security, who analyzed the attack, described the rat dropper's behavior: the script first detects your operating system, then reaches out to a command-and-control server to fetch a second-stage payload specifically tailored to your OS. Once downloaded, it establishes remote access to your machine.

Then comes the really clever part: it cleans up after itself. The script deletes evidence, removes the post-install script, and sanitizes the package.json. When you run npm audit, everything looks fine. No red flags. No warnings.

"The scariest thing is that Axios itself contains zero lines of bad source code," the analysis notes. "Instead of just hard-coding a crypto miner into the package like a noob, the attacker slipped a rogue dependency into the release."

Check Your System Right Now

If you use Axios, here's what you need to do immediately:

Open your package.json and look for these specific Axios versions: [the video doesn't specify exact versions, but Step Security's writeup would have them]
Check your node_modules folder for a package called plain-crypto-js
Run OS-specific commands to scan for the RAT file itself (Step Security has the exact commands for Mac, Windows, and Linux)

If you find the RAT, here's the uncomfortable truth: deleting it isn't enough. The malware could have already exfiltrated your AWS credentials, API keys, environment variables, and anything else accessible from your development machine or CI/CD server.

Step Security recommends immediately rolling all API keys and tokens. That means everything—not just the ones you think might be exposed. If the RAT had access to your machine, assume it had access to everything on your machine.

The npm Account Compromise

How did malicious packages get published under the Axios name in the first place? The same way most of these attacks start: account compromise.

Normally, Axios releases are published via GitHub Actions—automated deployments that don't require human intervention or stored credentials. But these malicious versions were published manually using an npm access token, traced back to a Proton Mail address.

How the attacker obtained that token remains unclear. Phishing? Credential stuffing? A compromised maintainer machine? The investigation is ongoing, but the attack vector matters less than the architectural question it raises.

The Uncomfortable Questions

This attack exposes tensions in how we build software that we don't talk about enough.

First: Why are we still using Axios? Modern JavaScript runtimes have native fetch support. Axios made sense a decade ago when promises were new and the web platform was behind. But today? We're accepting supply chain risk for... slightly nicer error handling?

I'm not saying everyone should immediately rip out Axios (especially not right now, while you're checking if you're compromised). But the instinct to reach for third-party libraries for things the platform now handles natively—that instinct has costs we're only beginning to calculate.

Second: npm's post-install script problem isn't new. We've known for years that arbitrary code execution during package installation is a massive attack surface. Some have argued for sandboxing these scripts or requiring explicit user consent. Others point out this would break legitimate use cases.

What's frustrating is that npm audit gives developers a false sense of security. It checks for known vulnerabilities in your dependency tree—it doesn't catch novel attacks like this one. When the malicious code removes its own traces, audit tools are checking for ghosts.

Third, and this is the one that really gets me: our supply chain is built on trust at scale that might not be sustainable. The average Node.js project has hundreds of dependencies, each maintained by strangers who could have their accounts compromised at any moment. We've created a system where a single weak password can potentially compromise millions of developers.

What This Means for JavaScript Security

The sophistication here suggests this wasn't some script kiddie. The attacker understood npm's lifecycle hooks, knew how to avoid detection, and built infrastructure (command-and-control servers, OS-specific payloads) that indicates planning and resources.

"If your system is compromised, the rat could already have access to your AWS credentials, your OpenAI API keys, and everything else in your file," the report warns. That's not hyperbole—that's the actual threat model.

What's interesting is what this attack didn't do. No ransomware. No immediate monetization. Just quiet credential theft and remote access. That pattern suggests either a nation-state actor collecting intelligence, or someone building a botnet for later use. Neither option is comforting.

The JavaScript security community has been warning about supply chain attacks for years. We got close calls with event-stream in 2018 and ua-parser-js in 2021. Each time, we collectively said "we should really do something about this" and then... mostly didn't.

Maybe this one will be different. Or maybe we'll patch, update our dependencies, and keep building on the same shaky foundation until the next attack. The architecture that makes JavaScript development fast and convenient is the same architecture that makes attacks like this possible. We can't fix one without confronting the other.

For now: check your systems, roll your keys, and maybe—just maybe—think twice before npm installing that next dependency.

Yuki Okonkwo is Buzzrag's AI & Machine Learning Correspondent