A Trusted Package Turned Into a Trap
Here's a scenario that should make any developer's stomach drop. You're running a routine npm install, updating a package you've used a hundred times, one that 100 million people download every single week — and somewhere in that process, you just let a remote access trojan onto your machine.
That's exactly what happened with Axios. On March 31, an attacker hijacked the npm account of Axios lead maintainer Jason Saayman and, within 39 minutes, published two backdoored releases: versions 1.14.1 and 0.30.4. Those poisoned packages were live on the npm registry for roughly three hours before anyone caught them. Three hours. That sounds short, but given Axios's scale, it was more than enough time to do serious damage.
How the Attack Actually Worked
The clever — and genuinely unsettling — part is how clean this looked on the surface. The malicious versions introduced a phantom dependency called [email protected], designed to look like the legitimate crypto-js library. A classic typosquat. Once installed, a postinstall script kicked off and downloaded platform-specific RAT payloads for Windows, macOS, and Linux.
And here's the kicker: the attacker didn't touch the GitHub repository at all. They bypassed the project's normal GitHub Actions CI/CD pipeline entirely, publishing directly with a stolen npm access token. No commits. No tags. No trace in the source code. As the Axios project's own post-mortem put it, the malicious versions "exist only on npm" — which means all the code review protections in the world wouldn't have caught this.
Both Microsoft and Google attributed the attack to North Korean state-backed threat actors. Microsoft Threat Intelligence identified the group as Sapphire Sleet; Google's team tracked the same activity under UNC1069.
What CISA Is Telling You to Do
On April 20 — nearly three weeks after the initial attack — the Cybersecurity and Infrastructure Security Agency issued a formal alert. The core message: if your organization installed Axios updates during the exposure window, assume compromise and act accordingly.
Immediate Steps
The remediation guidance is clear and urgent:
- Downgrade immediately to
[email protected]or[email protected] - Delete the malicious
plain-crypto-jsdependency from all environments - Rotate all potentially exposed credentials — and they mean all of them: version control tokens, CI/CD secrets, cloud keys, npm tokens, SSH keys
- Block outbound connections to
Sfrclak[.]comdomains - Run EDR hunts for indicators of compromise across affected endpoints
- Enable phishing-resistant MFA across all developer accounts
Longer-Term Hardening
Beyond the immediate cleanup, CISA recommends setting ignore-scripts=true in npm configuration files. This prevents install-time script execution — the exact mechanism the attacker exploited. They also suggest adopting a minimum release age of seven days before pulling in new package versions, which gives the community time to spot anything suspicious before it lands in your build.
The Scale of This Is Hard to Wrap Your Head Around
Huntress reported observing at least 135 endpoints across its partner network contacting the attacker's command-and-control infrastructure during the exposure window. And that's just what one security company observed in its own partner base.
Axios has over 174,000 dependent packages. It underpins huge portions of the JavaScript ecosystem. So a single compromised maintainer account — one stolen npm token — turned one of the most trusted packages on the internet into a malware delivery mechanism. That's the blast radius we're talking about.
And it's not happening in isolation. Sonatype's Q1 2026 Open Source Malware Index logged 21,764 malicious packages in just the first quarter of this year — roughly one every six minutes. The npm registry accounted for 75% of those. The cumulative total since 2017 is now approaching 1.35 million malicious packages.
The Real Gap This Exposes
What makes this incident so uncomfortable isn't just the scale — it's what it reveals about how open-source security actually works. We've built strong protections around code review, pull request workflows, signed commits. But the publishing layer? That's a different story.
An attacker with a stolen token can skip all of that. They don't need to fool a code reviewer. They don't need to merge a malicious PR. They just need one set of credentials and three hours on a Saturday.
The gap between "what's in the repository" and "what's published to the registry" is real, and this attack exploited it perfectly.