Axios vulnerability 2026: what actually happened in the npm supply-chain attack

Searches for "Axios vulnerability" have exploded over the last 48 hours, but that phrase is slightly misleading. What happened on March 31, 2026 was not primarily another ordinary Axios code bug in request handling. It was a compromise of the official Axios package on npm. Two malicious releases - [email protected] and [email protected] - were published through a compromised maintainer path, pulled in [email protected], and executed a cross-platform remote access trojan during installation via a postinstall hook. That is why the right mental model is "supply-chain compromise" rather than "library bug." According to GitHub's official malware advisory, any machine that installed or ran those versions should be treated as fully compromised. (GitHub)

The reason this incident immediately became global news is simple: Axios sits very deep in the JavaScript ecosystem. GitHub's dependency graph currently shows roughly 17,146,874 dependent repositories and 243,018 dependent packages, while Google Threat Intelligence Group says the affected Axios lines typically see more than 100 million and 83 million weekly downloads. Those numbers are not a victim count, but they explain why even a short malicious publication window created internet-scale concern. (GitHub)

What is verified, what is inferred, and what is still unknown

The verified facts are unusually strong for such a recent incident. The malicious versions were exactly 1.14.1 and 0.30.4. The campaign window was roughly three hours, beginning around 00:21 UTC on March 31, 2026. The infection path was an added dependency, [email protected], whose postinstall script ran node setup.js automatically on install. The malware then fetched a second-stage payload from attacker infrastructure and left platform-specific artifacts on macOS, Windows, and Linux. Those details appear consistently across the GitHub advisory, GTIG's write-up, Microsoft's incident analysis, Elastic's reverse engineering, and Snyk's remediation guide. (GitHub)

Expert consensus is also converging on attribution, though the vendor names differ. GTIG attributes the campaign to UNC1069, while Microsoft attributes the Axios infrastructure and compromise to Sapphire Sleet, a North Korea-linked actor, and notes overlap with UNC1069 and related tracking. The informed inference - and it is an inference, not a publicly confessed motive - is that the attackers cared less about Axios itself than about what Axios could reach: developer laptops, CI/CD runners, cloud credentials, package tokens, signing keys, and source repositories. What is still unknown is the exact initial path used to compromise the maintainer's publishing authority and the true global number of affected systems. Public telemetry so far is partial: Huntress reports at least 135 affected endpoints in its own partner base, but that is not a worldwide total. (Microsoft)

How the Axios compromise actually worked

What made this attack technically elegant - and operationally frightening - was its restraint. The attacker did not need to rewrite Axios itself. Instead, they added a single hidden dependency to the package manifest of two new Axios releases. That dependency, [email protected], looked close enough to a legitimate crypto package to avoid instant suspicion, and its postinstall hook executed silently during a routine install. Before detonation, the attacker had even published a clean-looking [email protected] to build harmless registry history, a detail documented by Elastic, Snyk, and Huntress. (elastic.co)

From there, the chain was simple and devastating. npm resolved Axios, pulled [email protected], ran node setup.js, detected the operating system, and contacted the attacker's C2 infrastructure. According to GTIG, the malicious hook was explicitly declared in package.json as postinstall: "node setup.js". According to Microsoft, the malware reached out to sfrclak.com:8000/6202033 and pulled a platform-specific payload. According to Snyk, the dropper then erased its own obvious traces by deleting setup.js, deleting the malicious manifest, and replacing it with a clean-looking stub. That matters because post-incident inspection of node_modules/plain-crypto-js could look deceptively normal. (Google Cloud)

There is another detail here that security teams should not miss. GTIG says the compromised maintainer email was changed to [email protected], and Huntress reports that the attacker bypassed the normal GitHub Actions OIDC-based publish flow by using a long-lived npm access token. Huntress goes further: even though trusted publishing had been configured for the v1.x line, the workflow still exposed an NPM_TOKEN, and npm used the token when both token-based and OIDC-based options were present. In other words, this was not just an "npm got hacked" story. It was also a story about how partial supply-chain hardening can leave a dangerous fallback path in place. (Google Cloud)

Why this was more dangerous than a normal Axios bug

A normal library vulnerability is usually about application behavior: SSRF, XSS, prototype pollution, memory exhaustion, request smuggling, something like that. This was different. The malware executed at install time, not only at runtime. That means a developer did not need to call the vulnerable code path, import a bad module manually, or even deploy the application. A simple npm install, CI build, package refresh, or transitive dependency resolution during the exposure window could be enough to compromise the host. That is why GitHub tells responders to treat affected machines as fully compromised rather than merely patched. (GitHub)

The second reason it was so dangerous is that the payloads were built for all three major desktop and server environments. Microsoft describes a macOS binary dropped at /Library/Caches/com.apple.act.mond, a Windows chain that copied PowerShell to %PROGRAMDATA%\\wt.exe, and a Linux Python payload written to /tmp/ld.py. GTIG describes WAVESHAPER.V2 as a fully functional RAT capable of reconnaissance, script execution, directory listing, and follow-on payload execution, with Windows persistence via a Run key. This was not a simple credential grabber or crude prank package. It was a cross-platform remote access framework delivered through a trusted dependency. (Microsoft)

How big was the impact?

There are two honest ways to answer that question. The first is ecosystem reach, and the answer there is enormous. Axios is depended on by about 17.1 million repositories and 243,018 packages on GitHub, and the affected release lines typically attract over 100 million and 83 million weekly downloads. That is why this incident dominated security feeds so quickly. Even if only a small fraction of those installs resolved during the malicious window, the potential blast radius was still extraordinary. (GitHub)

The second answer is confirmed victim telemetry, and here we need to be more careful. No public source I found publishes a verified global total. The strongest field number so far comes from Huntress, which says it observed at least 135 endpoints across all operating systems contacting the attacker infrastructure during the exposure window. Huntress also reports that the first infection on a monitored endpoint occurred only 89 seconds after [email protected] was published. That is a remarkable and important detail because it shows how quickly automated CI/CD, dependency bots, and developer machines can turn a three-hour package compromise into an immediate operational incident. (Huntress)

Who was actually at risk?

The high-risk population was not "everyone who has ever used Axios." It was anyone whose environment freshly resolved and installed the malicious versions during the publication window, whether directly or transitively. That includes developer laptops, CI pipelines, scheduled builds, container image builds, ephemeral runners, and dependency update bots. Snyk is explicit that the danger came from a fresh install during the window, not from merely having Axios somewhere in application code. Huntress likewise emphasizes that any environment resolving to 1.14.1 or 0.30.4 may have executed the payload automatically. (Snyk)

That also means some teams were naturally protected. If your package-lock.json, yarn.lock, pnpm-lock.yaml, or bun.lock had already pinned a different Axios version before the malicious release and your install did not update it, your risk was much lower. This is one of the clearest lessons from the incident: lockfiles are not bureaucracy. They are a core supply-chain control. Snyk says plainly that teams whose lockfiles were committed before the malicious versions were published, and not changed during installation, were not affected by this attack path. (Snyk)

How to check whether you were exposed

Start with lockfiles and dependency trees, not with application source code. Search your lockfiles for 1.14.1, 0.30.4, and plain-crypto-js. Then search host and network telemetry for platform-specific indicators like /Library/Caches/com.apple.act.mond, %PROGRAMDATA%\\wt.exe, /tmp/ld.py, or outbound traffic to sfrclak.com and 142.11.206.73. If you find any of those indicators, GitHub's advisory says the host should be considered fully compromised, and secrets should be rotated from a different machine. Microsoft's guidance also recommends ignoring postinstall scripts where possible, removing the compromised files, pinning safe versions, and rebuilding affected systems rather than trusting cleanup on the same host. (GitHub)

grep -E 'axios.*1\.14\.1|axios.*0\.30\.4' package-lock.json yarn.lock pnpm-lock.yaml 2>/dev/null
grep -R 'plain-crypto-js' package-lock.json yarn.lock pnpm-lock.yaml 2>/dev/null
npm ls plain-crypto-js 2>/dev/null

Those quick checks align closely with the public guidance from Microsoft and Snyk. But if a machine actually installed the malicious versions, do not stop at grep. Rotate credentials, review logs for lateral movement, and rebuild from a known-good image or snapshot. The most important point is that "remove the package and move on" is not considered sufficient by the primary sources. (Microsoft)

Is Axios safe now?

Yes, but with an important nuance that has confused many people. GitHub's advisory lists "patched versions: none." That does not mean Axios as a whole has no safe release. It means there is no "patched 1.14.1" or "patched 0.30.4" because the advisory is tracking two malicious artifacts, not a conventional software defect. For immediate rollback, Microsoft and Elastic recommend 1.14.0 for the 1.x line and 0.30.3 for the 0.x line, and Axios' official releases page shows both as legitimate releases. Snyk adds a broader clarification: any version other than 1.14.1 or 0.30.4 is clean with respect to this specific compromise. (GitHub)

This was not the same as earlier Axios CVEs

One reason the search term "Axios vulnerability" is confusing is that Axios really has had ordinary code-level vulnerabilities too. Those are separate from the March 2026 npm compromise. GitHub's advisory for CVE-2025-27152 describes a high-severity SSRF and credential leakage issue involving absolute URLs overriding baseURL, fixed in 1.8.2 and 0.30.0. CVE-2025-58754 describes a high-severity Node.js data: URI memory exhaustion issue, fixed in 1.12.0 and 0.30.2. CVE-2026-25639 describes a mergeConfig __proto__ denial-of-service issue, fixed in 1.13.5 and 0.30.3. And CVE-2023-45857 describes an earlier XSRF token leakage problem, fixed in 1.6.0 and 0.28.0. (GitHub)

That distinction is not pedantic. It changes the response. A normal CVE usually asks you to upgrade to a patched version and perhaps validate application behavior. A malicious package compromise asks you to think like an incident responder: what installed it, what secrets were present, what hosts contacted the C2, whether persistence was established, and whether the environment should be rebuilt. If you remember only one sentence from this article, let it be this: the "Axios vulnerability" that dominated headlines this week was first and foremost a supply-chain malware event. (GitHub)

What this incident says about open source security

The deepest lesson here is not "never trust open source." That would be shallow and wrong. The real lesson is that the security model around open source is shifting from source code review to pipeline integrity. This campaign succeeded not because Axios was obscure or unmaintained, but because it was trusted, popular, and automatically installed everywhere. It also exposed a hard truth about partial hardening: Huntress' reporting suggests that configuring OIDC trusted publishing is not enough if a long-lived token still exists as a viable fallback. Meanwhile, Microsoft's guidance on pinning versions, restricting auto-updates, and using --ignore-scripts where feasible makes clear that build systems now need runtime protections, not just dependency scanning. (Huntress)

The other lesson is cultural. Teams still tend to treat npm install as a harmless housekeeping action. This incident shows that it is an execution event. It can start processes, write files, call out to the network, and compromise machines before the application itself ever runs. That should change how organizations think about CI isolation, developer workstation telemetry, lockfile discipline, package provenance, secret placement, and outbound network monitoring in build environments. If there is one positive outcome from the Axios incident, it may be that it finally pushes more teams to treat software supply chains as production attack surfaces rather than as passive plumbing. (Huntress)

Conclusion

The March 2026 Axios incident matters because it collapses several uncomfortable truths into one case study. A single trusted package can become a delivery mechanism for malware. A three-hour window can be enough for broad exposure when automation is everywhere. "Just upgrade" is not a complete answer when the real target is developer and CI infrastructure. And the phrase "Axios vulnerability" can hide the most important fact of all: this was not only about a bug in a library. It was about trust in the software supply chain, and what happens when that trust is weaponized at scale. (GitHub)