Axios npm Supply Chain Attack 2026: How a Stolen Token Compromised 100 Million Downloads

Nobody noticed the dependency was already there, waiting.

On the morning of March 31, 2026, developers across the globe ran npm install as they do every single day, automatically, routinely, without a second thought. What most of them didn’t know was that somewhere between 00:21 and 03:15 UTC, that routine command had been quietly weaponised.

The axios npm package, the most popular JavaScript HTTP client in existence, installed over 100 million times a week, had been poisoned.

And the poison had been placed there 18 hours in advance.

What Is Axios And Why Does It Matter?

Axios is the HTTP client that JavaScript developers reach for almost without thinking.

It sits inside frontend React apps, Node.js backends, CI/CD pipelines, serverless functions, and enterprise microservices. It simplifies the otherwise tedious job of making HTTP requests, handling responses, errors, interceptors, and timeouts in a clean, promise-based API. It ships with virtually every serious JavaScript project.

That scale is exactly what made it a target. When an attacker compromises Axios, they’re not hitting one app. They’re hitting the entire JavaScript supply chain.

How the Attack Actually Worked

Figure 1: The axios attack demonstrated how modern supply chain compromises weaponise trust, automation, and developer routine at internet scale.

Step 1: Pre-staging the Weapon

The operation was not improvised. Nearly 18 hours before the malicious Axios versions appeared on npm, a package called plain-crypto-js@4.2.1 was quietly published. A clean decoy version (4.2.0) had gone up hours earlier, a tactic designed to make the package look like it had a legitimate history, reducing suspicion from automated scanners that flag brand-new packages.

The chess pieces were already on the board. The attacker just needed the account.

Step 2: Account Takeover

The lead Axios maintainer, Jason Saayman, later confirmed his account was compromised through a targeted social engineering campaign. The attacker gained access to his machine via RAT malware and, from there, stole his npm authentication token, bypassing GitHub Actions’ OIDC Trusted Publisher safeguards entirely, since they were published manually. It wasn’t a zero-day. It wasn’t a technical exploit in npm’s infrastructure. It was a human being, targeted deliberately, who became the unlock key to a hundred-million-download package.

Step 3: Publishing Two Poisoned Versions

Within a 39-minute window, two backdoored releases were pushed: axios@1.14.1 and axios@0.30.4. Both injected plain-crypto-js@4.2.1 as a dependency. Both branches, the current release and the legacy branch, were hit simultaneously.
Since most projects use semver ranges like ^1.14.0, fresh installs and CI builds automatically pulled the poisoned version. No one had to manually upgrade.

Step 4: Execution and Self-Destruction

During installation, npm automatically executed a postinstall hook, a built-in npm feature, which ran an obfuscated file called setup.js. This dropper connected to a command-and-control server (sfrclak[.]com) and downloaded a platform-specific payload: a cross-platform Remote Access Trojan targeting macOS, Windows, and Linux.
This is the part that makes detection hard: the malware replaced its own files with clean decoys and self-destructed its footprint. The malicious versions were live for approximately three hours before being removed. In those three hours, the damage was done.

Who Did This?

Both Microsoft Threat Intelligence and Google’s Threat Intelligence Group attributed the attack to a North Korean state-sponsored actor. Microsoft identified them as Sapphire Sleet. Google’s team, tracking the same actor as UNC1069, identified the malware as an updated version of a backdoor they call WAVESHAPER, a tool with known ties to North Korean cyber operations active since at least 2018.

The motivation appears financial, consistent with North Korea’s broader pattern of targeting developer toolchains to infiltrate organisations for cryptocurrency theft, credential harvesting, and long-term espionage.

This wasn’t random. It was surgical.

Real-World Impact and What Organizations Faced

Huntress observed over a hundred affected devices in their telemetry during the three-hour window. The actual global exposure was significantly larger; any developer or CI pipeline that ran npm install during the window and resolved to either a poisoned version was at risk.

The practical implications were severe:

  • Any system that installed the compromised version should be treated as fully compromised.
  • CI/CD pipelines, which run installs automatically, were particularly exposed.
  • The self-destructing nature of the malware meant many affected systems showed no obvious indicators initially.
  • The RAT provided persistent remote access, meaning attackers could return even after the malicious package was removed.

CISA issued a formal advisory on April 20, 2026, recommending organisations downgrade to axios@1.14.0 or axios@0.30.3, delete the node_modules/plain-crypto-js directory, rotate all credentials on affected systems, and audit CI/CD pipeline histories.

The Larger Shift This Represents

Figure 2: The modern software supply chain runs on invisible trust relationships between maintainers, registries, dependencies, and automation systems. The axios incident demonstrated how fragile those relationships become when a single trusted link is compromised.

We’ve built the modern internet on a foundation of implicit trust.

Every time a developer types npm install, they are trusting that the package registry, the maintainer’s account, and the maintainer’s personal machine are all uncompromised. That trust is structural, baked into how we build software. And increasingly, adversaries know it.

The Axios attack is not an anomaly. It follows a pattern: identify a high-trust, high-download package, compromise a human maintainer rather than the code itself, stage the payload in advance, execute quickly, and clean up before detection. The npm ecosystem’s openness, its greatest strength, becomes the attack surface.

What makes this attack particularly sobering is the economics. A single stolen npm token accessed one hundred million potential installation events. The ratio of effort to impact is staggering.

The question isn’t whether this will happen again. It’s which package is next.

Key Takeaways

  • The Axios compromise began with a stolen maintainer token, not a vulnerability in npm itself, turning a trusted developer account into the entry point for a massive supply chain attack.
  • Nearly 18 hours before the poisoned axios versions appeared, attackers quietly staged a malicious dependency designed to look legitimate and avoid immediate suspicion.
  • Because most JavaScript projects rely on automated semver updates, developers and CI/CD pipelines pulled the compromised versions through completely routine npm installs.
  • The attack chain abused normal ecosystem behaviour, post-install hooks, dependency resolution, and automated package installs, making the compromise difficult to distinguish from legitimate activity.
  • The malware’s ability to self-delete and replace its own files with clean decoys meant many affected systems showed little or no visible evidence after compromise.
  • More than a package breach, the Axios incident exposed a larger problem within modern software ecosystems: development at internet scale depends heavily on invisible trust relationships that attackers increasingly know how to exploit.

Conclusion

The Axios compromise is a reminder that the most dangerous vulnerabilities in modern software aren’t always found in code. They’re found in people, in the trust we place in maintainers, and the trust maintainers place in their own security.

Three hours. Two poisoned packages. One stolen npm token. A hundred million potential targets.

The fix for any individual developer is straightforward: downgrade, audit, and rotate credentials. But the systemic fix, deciding how to protect an open-source ecosystem built on voluntary maintainership, is far harder. npm has introduced mechanisms like OIDC publishing and mandatory 2FA, but as this attack showed, motivated adversaries find the human bypass.

The next supply chain attack is already being planned.
The real question is, are you building your systems assuming trust or verifying it?

Share your love
Keerthana Srinivas
Keerthana Srinivas
Articles: 85

Leave a Reply

Your email address will not be published. Required fields are marked *