Sometime around midnight UTC on March 31, 2026, an attacker published two malicious versions of Axios to npm. Axios is one of the most widely used HTTP client libraries in the JavaScript ecosystem, with over 83 million weekly downloads. The malicious versions injected a cross-platform remote access trojan that targets Windows, macOS, and Linux.
This was not a typosquat. This was not a proof of concept. Someone compromised the primary maintainer's npm account, published poisoned packages on two separate release branches within 39 minutes of each other, and built payloads that self-destruct after execution. The malicious versions have been pulled from npm, but if your team installed them during the window, you have a problem that goes well beyond reverting a package version.
What Happened
The attack unfolded in stages. On March 30 at 05:57 UTC, a clean npm package called "plain-crypto-js" version 4.2.0 was published. It looked harmless. Eighteen hours later, at 23:59 UTC, version 4.2.1 of the same package was published with an embedded payload. Then the real move: at 00:21 UTC on March 31, Axios version 1.14.1 was published with "plain-crypto-js@4.2.1" injected as a runtime dependency. Thirty-nine minutes later, Axios version 0.30.4 followed with the same malicious dependency.
Both Axios versions were published using the compromised npm credentials of the project's primary maintainer, "jasonsaayman." The attacker changed the account's registered email to a Proton Mail address under their control. The "plain-crypto-js" package itself was published by a separate npm user, "nrwise," also using a Proton Mail address. StepSecurity, the firm that discovered the attack, believes the attacker obtained a long-lived classic npm access token for the maintainer account.
StepSecurity researcher Ashish Kurmi put it plainly: "This was not opportunistic. The malicious dependency was staged 18 hours in advance. Three separate payloads were pre-built for three operating systems. Both release branches were hit within 39 minutes. Every trace was designed to self-destruct."
What the Malware Does
The injected "plain-crypto-js" package runs a postinstall script that acts as a RAT dropper. When npm installs the package, the script executes automatically. It detects the operating system and branches into one of three attack paths.
On macOS, it runs an AppleScript payload that downloads a trojan binary from an external command and control server, saves it to a hidden cache directory, makes it executable, and launches it in the background. The AppleScript file is deleted after execution.
On Windows, it copies the PowerShell binary to a new location disguised as the Windows Terminal application, then writes and executes a VBScript that initiates the second-stage payload download.
On Linux, the dropper follows a similar pattern with a platform-specific binary.
In all three cases, the malware contacts a live C2 server, downloads a second-stage payload tailored to the operating system, executes it, then cleans up after itself. The malicious package.json is replaced with a clean version to make forensic detection harder. This is not amateur work.
The attacker built three OS-specific payloads, staged the delivery package 18 hours early, hit both release branches in under 40 minutes, and designed every artifact to self-destruct. This was planned.
Why This Matters Beyond JavaScript
Axios is not a niche library. It is used in React frontends, Node.js backends, enterprise microservices, internal tooling, and CI/CD pipelines. If your organization builds software with JavaScript or TypeScript, there is a meaningful chance Axios is somewhere in your dependency tree. Often in multiple places.
Supply chain attacks against npm packages are not new. We covered the LiteLLM backdoor just last week. But the Axios compromise stands out because of the target's popularity, the sophistication of the attack staging, and the fact that the attacker bypassed the project's GitHub Actions CI/CD pipeline entirely by going straight through compromised npm credentials. Code review, branch protection rules, and CI checks were all irrelevant because the malicious versions were published directly to the registry.
That is the uncomfortable reality of software supply chain security in 2026. Your security controls on the source code repository do not help if an attacker can publish directly to the package registry with a stolen token.
Worried about supply chain exposure in your applications? A penetration test that includes dependency and build pipeline review can identify whether compromised packages made it into your environment. See how our assessments work or book a scoping call.
What to Do Right Now
If your team uses Axios (and statistically, they probably do), here is the immediate checklist.
1. Check your installed versions. Run npm ls axios or yarn why axios across every project, CI runner, and deployment environment. If you find version 1.14.1 or 0.30.4, you were affected.
2. Downgrade immediately. Safe versions are 1.14.0 and 0.30.3. Pin them in your package.json and lock files. Do not rely on semver ranges to protect you here.
3. Rotate secrets and credentials. If a malicious version was installed in any environment, assume that environment is compromised. That means API keys, database credentials, service account tokens, environment variables, SSH keys, and anything else accessible from that machine. Rotate all of them. This is not optional.
4. Check for indicators of compromise. Look for unexpected processes, outbound connections to unfamiliar domains (particularly sfrclak.com), files in unusual locations like /Library/Caches/com.apple.act.mond on macOS or %PROGRAMDATA%\wt.exe on Windows, and any recently created scheduled tasks or launch agents.
5. Review your npm token hygiene. This attack succeeded because of a long-lived classic npm access token. If your organization publishes npm packages, check whether your maintainers are using classic tokens without expiration. Switch to granular access tokens with short lifetimes and enable two-factor authentication on all npm accounts that have publish access.
The Larger Problem: You Cannot Audit What You Cannot See
Most organizations have no real-time visibility into what their developers install from public registries. Package lock files help with reproducibility, but they do not prevent a compromised version from being locked in during the window between publication and discovery. Automated dependency scanning tools are useful, but they rely on vulnerability databases that are populated after someone identifies the problem. In the gap between compromise and detection, you are exposed.
This is exactly why security assessments need to include the software supply chain. A traditional network penetration test will not find a backdoored npm dependency sitting on your build server. But a security assessment that reviews your dependency management practices, build pipeline controls, and registry authentication will surface these risks before they become incidents.
The pattern is clear now. SolarWinds. Codecov. ua-parser-js. event-stream. LiteLLM. Axios. The supply chain is the attack surface, and most organizations treat it as someone else's problem.
When was the last time someone reviewed your build pipeline security? If the answer is "never" or "I am not sure," that is a finding in itself. Let's talk about what a supply chain review looks like.
The Bottom Line
Axios, a package installed on millions of machines worldwide, was backdoored through a compromised maintainer account. The malicious versions were live on npm for a window of hours, delivered a cross-platform RAT with self-destructing artifacts, and bypassed every source code control the project had in place.
If your organization builds software, check your Axios version today. If it was 1.14.1 or 0.30.4, treat the environment as compromised and begin incident response. And if you have never had someone look at the security of your build and deployment pipeline, this is a good day to start that conversation.
Your Code Is Only as Secure as Your Supply Chain
Our security assessments go beyond the network perimeter to evaluate dependency management, build pipeline controls, and registry security. Clear findings. Practical fixes.
See Our Security Services