Axios npm Supply Chain Attack: Post-Mortem and Everything We Know So Far

The Axios npm compromise has quickly become one of the most important software supply chain incidents of 2026, not because the attackers poisoned a lookalike package, but because they published malicious versions of the real Axios package through a compromised maintainer account. What followed was a short but dangerous exposure window in which routine dependency resolution could turn developer workstations, CI/CD runners, and build environments into malware delivery points.

Here is what we know so far.

On March 31, 2026, two malicious Axios versions, 1.14.1 and 0.30.4, were published to npm through the compromised account of the lead maintainer. Those releases introduced a malicious dependency, plain-crypto-js@4.2.1, which executed during installation and downloaded a remote access trojan for macOS, Windows, and Linux. Axios maintainer Jason Saayman later confirmed in a public post-mortem that the malicious versions were live for about three hours before removal.

That detail is critical. The Axios codebase itself was not silently rewritten into a backdoor. Instead, the attacker made a smaller and more surgical change by injecting a malicious dependency into the package manifest while leaving the main application logic untouched. That made the malicious releases more likely to blend in, especially in environments where teams trust patch-level updates and do not deeply inspect transitive dependencies.

The compromise chain now appears much clearer than it did in the first few hours of disclosure. According to the maintainer’s write-up, the attacker gained access to the lead maintainer’s PC through a targeted social engineering campaign followed by RAT malware, and then used that access to publish the poisoned Axios versions. Saayman says the incident was the result of unauthorized access to his account rather than a direct change to the underlying Axios source repository.

Microsoft Threat Intelligence has since gone further, attributing the infrastructure and the Axios npm compromise to Sapphire Sleet, a North Korean state actor. Microsoft says the account that created the malicious plain-crypto-js package was associated with Sapphire Sleet infrastructure, and that the malware fetched second-stage payloads from a command-and-control server already tied to the group. That turns the Axios incident from a major open source package compromise into a probable nation-state-linked supply chain intrusion.

The malicious dependency itself was designed for silent install-time execution. Microsoft says plain-crypto-js@4.2.1 used a postinstall hook to launch setup.js automatically during npm install or dependency resolution, with no user interaction required. That meant affected systems could be compromised even if developers never explicitly imported Axios in code after installation. The infection point was the package manager itself.

From there, the payload delivery differed by platform. On macOS, the malware dropped a native binary to /Library/Caches/com.apple.act.mond and launched it through AppleScript. On Windows, it dropped a VBScript stager and a PowerShell RAT, including %TEMP%\6202033.vbs and %TEMP%\6202033.ps1, then copied PowerShell to C:\ProgramData\wt.exe to disguise execution. On Linux, it wrote a Python loader to /tmp/ld.py and ran it with nohup python3. Microsoft says all variants used the same C2 base URL, hxxp://sfrclak[.]com:8000/6202033, with minor request differences to identify the operating system.

We also know the time window more precisely now. Saayman’s post-mortem says plain-crypto-js@4.2.0 was published on March 30 at 05:57 UTC, then axios@1.14.1 went live at 00:21 UTC on March 31, followed by axios@0.30.4 around 01:00 UTC. The first external detections and community reports appeared around the same time, but the attacker was reportedly able to delete some GitHub issue reports using the compromised account. The malicious Axios versions were removed from npm at 03:15 UTC, and plain-crypto-js was removed at 03:29 UTC.

That short timeline is part of what makes the event so instructive. This was not a long-dwell compromise that lingered unnoticed for days. It was a fast, high-impact supply chain strike in which the damage window was measured in hours, but the downstream consequences can last much longer because installations during that window may have leaked secrets or established persistent access on affected machines.

So who is affected? Based on the maintainer and Microsoft guidance, systems are at risk if they resolved axios@1.14.1, axios@0.30.4, or plain-crypto-js@4.2.1 during the exposure window. Saayman’s guidance says users pinned to clean versions and who did not perform a fresh install between 00:21 and 03:15 UTC on March 31 are fine. Everyone else should assume compromise if those versions appear in a lockfile or install output.

That is why the remediation guidance is much stronger than a normal package advisory. Both the maintainer and Microsoft say affected systems should not simply downgrade and move on. They should roll back to safe versions, remove the malicious dependency, rotate all secrets and credentials exposed to the compromised machine, review network logs for traffic to sfrclak[.]com or 142.11.206.73 on port 8000, and pay particular attention to CI/CD runners where environment-injected secrets may have been exposed during builds.

The incident also exposed structural weaknesses in how high-impact open source packages are published. Saayman’s post-mortem says publishing directly from a personal account was a risk that should have been removed earlier, and that the project is now moving toward an immutable release setup and proper OIDC-based publishing. He also notes that there was no automated way to detect an unauthorized publish, meaning detection depended on the community noticing something was wrong. That is a striking admission because it highlights how much of the trust in major open source distribution still depends on fragile human oversight.

There are also still open questions. The maintainer says the team is actively investigating how unauthorized access was obtained, but does not yet have confirmed details to share beyond the broader social-engineering and RAT-based compromise path. It is also not yet clear how many organizations actually installed the malicious versions during the live window, how many CI systems were exposed, or how widely the second-stage payloads succeeded in establishing durable access. Those answers will likely take longer because many victims may never realize they resolved the bad versions unless they now go looking for them.

What is already clear, though, is that the Axios event is now a case study in modern open source risk. A highly trusted package, a compromised maintainer endpoint, a malicious transitive dependency, install-time execution, cross-platform malware delivery, and probable nation-state attribution all converged in a single incident. The lesson is no longer just that maintainers are targets. It is that package publishing itself is now a strategic attack surface, and even a brief compromise can create downstream fallout across the global software supply chain.

What organizations should do right now

• Search lockfiles and dependency trees for axios@1.14.1, axios@0.30.4, and plain-crypto-js@4.2.1.
• Downgrade to axios@1.14.0 or 0.30.3 and remove the malicious dependency.
• Rotate all credentials, tokens, and secrets exposed to affected hosts or build jobs.
• Review network logs for connections to sfrclak[.]com or 142.11.206.73:8000.
• Disable broad auto-updates for Axios and pin exact versions or use overrides until release controls are fully hardened.
• Prefer trusted publishing with OIDC and reduce reliance on long-lived publishing credentials.

Reference Links and Sources

• Axios maintainer post-mortem and remediation update.
• Microsoft Threat Intelligence analysis and attribution to Sapphire Sleet.