A Familiar Name in a New Light
If you’ve written JavaScript in the last five years, you’ve probably used axios. It’s everywhere — over 100 million downloads a week. So when a malicious version of it quietly slipped out in early 2025, the ripple effect was felt across countless development teams.
Now we know who was likely behind it. AWS published a blog post on July 29 attributing the axios compromise — along with attacks on debug, chalk, and typo-crypto — to a North Korean state-sponsored hacking group tracked as Saphire Sleet, also known as BlueNoroff.
The connection wasn’t obvious at first. But Amazon Threat Intelligence dug into the tactics, techniques, and procedures (TTPs) across all four incidents and found striking similarities: trojanized npm packages, post-install hooks that execute automatically, and reused code.
“Amazon Threat Intelligence identified shared TTPs across these supply-chain campaigns, including trojanized NPM packages, use of post-install hooks, and code reuse,” said CJ Moses, CISO and VP of security engineering at Amazon. “Based on analysis of command-and-control indicators and TTPs, we assess with medium confidence that these campaigns are attributable to the DPRK-linked threat actor tracked as Saphire Sleet.”
Medium confidence. That’s a careful word choice — attribution is rarely a slam dunk. But the pattern is compelling.
The Same Playbook, Repeated
Here’s how the attacks unfolded. The group would socially engineer a package maintainer, gain their trust, and then publish a “legitimate” update that actually contained malicious code. Any organization that auto-updated dependencies received the compromised version without a second thought.
Moses said the typo-crypto compromise in March 2025 was likely a dry run. The real damage came later. In a two-hour window, roughly 10% of cloud environments pulled the compromised debug and chalk packages. Axios, being one of the most popular JavaScript libraries on the planet, amplified the reach even further.
The math is simple. “By compromising a small number of highly popular packages, the group gains potential access to thousands of downstream environments simultaneously,” Moses explained. For a financially motivated actor, that’s far more efficient than picking off targets one by one.
How Attacker Tradecraft Is Evolving
AWS didn’t just stop at attribution. The blog post also detailed how these attackers are getting smarter, and the list is sobering:
- Splitting malicious workflows across several innocent-looking packages to evade detection.
- Playing the long game — acting like real maintainers for weeks or months before dropping the malicious update.
- Keeping package contents benign, while the real danger hides in external scripts, config files, and remote endpoints.
- Using advanced obfuscation: AES-GCM encrypted blobs gated by passphrases, RC4-style string arrays with per-call keys, layered XOR over base64, and native loaders.
- Designing payloads to evade sandbox analysis.
- Slopsquatting — registering package names that AI coding tools hallucinate, tricking developers into installing malware.
That last one is particularly nasty. Developers increasingly rely on AI assistants to generate code, and those tools sometimes suggest package names that don’t exist. Attackers register those names first. You can see how that ends.
Should We Care Who’s Behind It?
Not everyone agrees that attribution matters much for defenders. Cris Thomas, security advocate at Semgrep, argues the focus should be elsewhere.
“Defenders should not concern themselves too much with who is performing an attack and more with knowing likely techniques of a specific attacker. Distinguishing between one group and another can be helpful for defense teams, knowing whether it is North Korea or Canada is less relevant.”
His advice? Defense in depth. “If one defense doesn’t find them, another one will. The goal isn’t to prevent successful attacks but to identify, limit, block, and correct attacks as soon as possible.”
That’s a fair point. Knowing the attacker’s name doesn’t patch your dependencies. But understanding their TTPs — the post-install hooks, the social engineering, the slopsquatting — gives you something concrete to defend against.
Practical Steps for Developers
So what can you actually do? A few things:
- Audit your dependencies regularly. Tools like
npm audit and software supply chain security scanners can flag suspicious packages.
- Lock your versions. Don’t auto-update blindly. Pin versions and review changes before upgrading.
- Beware of new packages. Especially ones that sound plausible but are slightly off — that’s slopsquatting territory.
- Monitor post-install scripts. These run automatically and are a favorite vector for attackers.
The axios npm attack is a reminder that open source is both a gift and a risk. The ecosystem runs on trust. When that trust is weaponized, the fallout is massive.
For more on how platforms are responding, check out our coverage of GitHub’s npm security updates.
