Yesterday, attackers slipped malicious code into axios — one of the most downloaded JavaScript packages on the planet, with over 100M installs every week¹. If you ran npm install in the last 24 hours and axios was involved, there is a real chance you now have a Remote Access Trojan sitting quietly on your machine.
This is not a theoretical risk. This is happening right now.
What You Need to Do First
Before you read another word, run this:
If either of those returns a result, treat your machine as compromised.
That means:
- Do not use it to access production systems or sensitive credentials until it has been rebuilt
- Rotate everything: SSH keys, AWS, GCP, and Azure credentials, API tokens, .env secrets, database passwords, and npm tokens
- Review your CI/CD pipeline logs from March 30 to 31 and rotate any secrets those pipelines touched
- On macOS, look for /Library/Caches/com.apple.act.mond — that is the RAT binary
- On Windows, look for %PROGRAMDATA%\wt.exe — that is a disguised PowerShell copy left behind by the attacker
- Block outbound traffic to sfrclak.com (port 8000) and 142.11.206.73 at your firewall²
Rebuild the machine. Do not try to clean it.
Here Is What Actually Happened
Here is the part that should concern every developer, not just axios users.
The attackers did not hack GitHub. They did not sneak a pull request past code reviewers. They stole 1 npm account password, and that was enough³.
With a single set of stolen credentials, they published 2 fake axios versions (1.14.1 and 0.30.4) directly to the npm registry⁴. No git tags. No commits. No trace in the GitHub repository. If you were checking GitHub to verify a release was legitimate, these versions are invisible. They do not exist there.
Those fake versions quietly pulled in a new dependency called plain-crypto-js, which fired malicious code the instant npm finished installing it⁵. That code reached out to an attacker-controlled server, downloaded a platform-specific payload, installed it silently, and then erased all evidence of itself⁶. By the time your install finished, the package looked completely clean.
The payload on macOS was a fully functional Remote Access Trojan. The attacker could push new programs to your machine, run shell commands, and enumerate your filesystem. Whenever they wanted. All while you were going about your day.
This Keeps Happening — and the Reason Is Structural
This is not bad luck. It is a pattern.
In 2021, the same thing happened to ua-parser-js — nearly 8 million weekly downloads, 1 hijacked account, cryptominer deployed overnight⁷. The attack demonstrates a fundamental vulnerability in how the npm registry distributes code.
Every time, the story is the same. The npm registry extends enormous trust to individual maintainer accounts. 1 stolen password. 1 disgruntled maintainer. 1 social engineering campaign. That is all it takes to push malicious code to millions of machines, instantly, automatically, silently.
When you run npm install, you are trusting that every maintainer in your entire dependency tree — not just the packages you explicitly chose, but their dependencies, and their dependencies’ dependencies — has not been compromised. That is a lot of people, a lot of accounts, and a lot of attack surface you do not control.
The Personal Liability Your Scanner Will Not Catch
Here is what gets lost in the post-incident cleanup. Your developers’ machines almost certainly held SSH keys, cloud credentials, API tokens, and access to production systems. The RAT that axios delivered had arbitrary command execution. It could have been used to exfiltrate those credentials quietly, days before anyone noticed.
If that happened in your environment, the question you will face is not “why did our scanner miss it.” It is “why did unvetted open source reach our developers’ machines in the first place.” In 2026, that is a question with regulatory consequences. The SEC and the EU Cyber Resilience Act have both shifted the burden of proof onto the security leader to demonstrate that software was secure at the point of origin. Scanning for vulnerabilities tells you the house is on fire. It does not put the fire out, and it is not a sufficient legal defense.
There Is a Better Way to Manage This Risk
We are not going to tell you to stop using open source. 96% of applications include it, and that is not changing.
What we will tell you is that the registry model was not designed with security as the primary concern. Speed and accessibility were. And the gap between those priorities is where software supply chain attacks live.
At ActiveState, we maintain a library of 79 million open source components built from source, not pulled as-is from public registries. Every component is scanned for CVEs and malware before it enters the library. Arbitrary postinstall hooks do not execute in your environment with your credentials. Every transitive dependency is tracked and visible, not resolved silently at install time. And when a compromise like this surfaces, you do not find out by reading a blog post.
The axios attack worked because there was no signal. A clean install, a quiet RAT, a clean-looking package directory. The information gap between what npm tells you and what actually happened is exactly where attacks like this live. Closing that gap is what we do.
The axios Team Responded Well — and That Is Not Enough
To their credit, the axios maintainers acted quickly. The malicious versions are being deprecated. The C2 server is offline. The immediate threat is contained⁸.
But the attacker already proved the concept. 1 credential, millions of potential victims, silent execution, self-erasing malware. That capability does not disappear because this particular campaign was shut down. Someone else is watching, taking notes, and picking their next target.
Stop planning for the “if” of a software supply chain attack. Start building the “how” of your remediation before the next one lands.
ActiveState provides the world’s largest library of secure, built-from-source open source components, delivered directly into the tools your teams already use. See how it works →
