Axios Compromised on npm: How a Hijacked Maintainer Account Turned 100 Million Weekly Downloads Into a RAT Delivery Network

On March 31, 2026, an unknown threat actor compromised the npm account of jasonsaayman, the primary maintainer of the Axios HTTP client library, and published two poisoned versions: axios@1.14.1 and axios@0.30.4. Both versions injected a dependency called plain-crypto-js@4.2.1 that executed a postinstall script deploying a cross-platform remote access trojan targeting macOS, Windows, and Linux. The malicious versions were live on npm for approximately two hours before removal.

Axios is one of the most widely used packages in the JavaScript ecosystem, present in roughly 80% of cloud and code environments according to Wiz. StepSecurity, which detected the attack, recorded the RAT calling home to the attacker’s command-and-control server within 1.1 seconds of running npm install. Vercel, Snyk, Socket, and Wiz have all published independent analyses. This was not opportunistic. This was a precisely staged operation against one of npm’s most trusted packages.

How the Attack Chain Worked

The attacker followed a five-step sequence designed to evade automated detection.

First, the attacker compromised jasonsaayman’s npm account and changed the registered email to an attacker-controlled ProtonMail address (ifstap@proton.me). Second, 18 hours before the main attack, the attacker published a clean version of plain-crypto-js@4.2.0 to build a brief publication history on the registry and avoid “new package” alarms from security scanners. Third, at 23:59 UTC on March 30, the attacker published the malicious plain-crypto-js@4.2.1. Fourth, at 00:21 UTC on March 31, axios@1.14.1 was published with plain-crypto-js@4.2.1 injected as a runtime dependency. Fifth, at 01:00 UTC, axios@0.30.4 followed, poisoning both the 1.x and 0.x release branches within 39 minutes.

The attacker bypassed Axios’s GitHub Actions CI/CD pipeline entirely by publishing directly through the npm CLI using the compromised account credentials. The malicious versions appeared on the npm registry as published by jasonsaayman, making them visually indistinguishable from legitimate releases.

What the RAT Does

The postinstall script in plain-crypto-js uses two layers of obfuscation: reversed Base64 encoding with padding character substitution, and XOR cipher with the key “OrDeR_7077” and a constant value of 333. Once decoded, the dropper checks the operating system and deploys a platform-specific payload.

On macOS, a RAT binary is stored at /Library/Caches/com.apple.act.mond, a path designed to mimic a legitimate Apple system process. On Windows, the malware copies PowerShell to %PROGRAMDATA%\wt.exe and executes a hidden script. On Linux, it downloads a Python script to /tmp/ld.py. All three payloads communicate with the same C2 server at sfrclak.com on port 8000.

After execution, the dropper performs three cleanup steps: it deletes itself, removes the package.json containing the malicious postinstall hook, and replaces it with a clean version. Anyone inspecting node_modules/plain-crypto-js afterward sees an innocent-looking package. The presence of the plain-crypto-js folder in node_modules is the forensic indicator that the dropper executed.

Why npm’s Trust Model Failed

The CanisterWorm attack earlier this month exploited stolen npm tokens to propagate across 47 packages. The Axios attack used the same fundamental vector: compromised maintainer credentials. npm’s registry treats any publish action authenticated with valid credentials as legitimate, regardless of whether the package’s source code matches its GitHub repository.

This is the third major npm supply chain attack in March 2026 alone. The Langflow CVE-2026-33017 exploited a different part of the AI tooling stack, but the pattern is the same: developer infrastructure has become a high-value attack surface because it sits upstream of everything else. A single compromised dependency cascades through every build system that pulls it.

Socket’s automated malware detection flagged plain-crypto-js within six minutes of publication. StepSecurity’s Harden-Runner detected the C2 callback during routine CI runs in the Backstage repository. But detection is not prevention. Any project using a caret version range (^1.14.0 or ^0.30.0) in its package.json would have pulled the compromised version automatically on its next npm install during the two-hour window.

Who Is Affected

Wiz reported observed execution in 3% of environments where the affected versions were present. Projects that ran npm install between 00:21 and approximately 03:15 UTC on March 31, 2026 and resolved to axios@1.14.1 or axios@0.30.4 should treat affected machines as fully compromised. StepSecurity recommends rotating all credentials on affected systems, including npm tokens, cloud API keys, SSH keys, and CI/CD secrets.

Vercel confirmed its own infrastructure was unaffected and blocked outgoing access to the C2 hostname. The npm registry removed the malicious versions and pointed the “latest” tag back to the safe axios@1.14.0 release.

What This Pattern Means

Three supply chain attacks against JavaScript developer infrastructure in a single month is not a coincidence. It reflects a structural vulnerability: the npm ecosystem’s trust model relies on individual maintainer account security, and individual maintainer accounts are exactly the kind of target that scales well for attackers. One compromised account, one package, millions of downstream installations.

The mitigations are known. Pin exact dependency versions. Use npm ci instead of npm install in CI/CD. Disable postinstall scripts by default (pnpm does this). Implement publish cooldown policies that reject packages less than 72 hours old. Require MFA on all publishing accounts. None of these are new recommendations. The Axios attack succeeded because the ecosystem has not adopted them at sufficient scale. Until it does, the supply chain remains the softest target in software security.

Sources: StepSecurity. Socket. Snyk. Wiz. Vercel. The Hacker News.