Axios Supply Chain Attack Delivers Cross-Platform RAT to Millions After npm Maintainer Account Hijacked
A coordinated supply chain attack targeting the Axios npm package has delivered a cross-platform remote access trojan to developer workstations and CI/CD environments worldwide, after an attacker hijacked the lead maintainer's npm credentials and published two backdoored releases to the official registry.
The attack, executed in the early hours of March 31, 2026, compromised the npm account of Axios's primary maintainer (jasonsaayman). The attacker changed the account's email to a ProtonMail address, then bypassed the project's normal GitHub Actions CI/CD publishing pipeline by publishing directly via the npm CLI using a long-lived access token. A critical misconfiguration enabled the bypass: even on the branch where OIDC Trusted Publishing was configured, the publish workflow still passed NPM_TOKEN as an environment variable alongside OIDC credentials — and when both are present, npm defaults to the token.
Two malicious versions were pushed: axios@1.14.1 (tagged latest) and axios@0.30.4 (tagged legacy). Neither contained malicious code in the Axios source itself. Instead, they introduced a phantom dependency — plain-crypto-js@4.2.1 — a package that had not existed prior to the attack and is never imported by Axios code. Its sole function was to execute a postinstall script that served as a dropper for the RAT.
The attack was carefully pre-staged. Approximately 18 hours before detonation, the attacker published a clean version of plain-crypto-js (v4.2.0) from a separate account to establish publishing history and reduce the chance of automated scanner flags. The malicious v4.2.1 was published just minutes before the compromised Axios versions went live.
The first infection on a Huntress-monitored endpoint landed 89 seconds after axios@1.14.1 was published — consistent with automated CI/CD pipelines using caret ranges that resolved the new version immediately on the next npm install. Within the roughly three-hour window before npm's security team pulled the packages, Huntress observed at least 135 endpoints across all operating systems contacting the attacker's command-and-control infrastructure.
The dropper (setup.js) used a two-layer obfuscation scheme combining reversed Base64 encoding with an XOR cipher, hiding module names, the C2 URL, and shell commands. On execution, it detected the host operating system and launched platform-specific payloads. On Windows, it wrote a VBScript that copied powershell.exe to %PROGRAMDATA%\wt.exe — deliberately mimicking Windows Terminal's filename to evade process-name heuristics — then downloaded and executed a PowerShell RAT. On macOS, an AppleScript fetched a compiled C++ Mach-O universal binary supporting both x86_64 and ARM64, disguised under Apple's own naming convention at /Library/Caches/com.apple.act.mond. On Linux, a Python RAT script was downloaded to /tmp/ld.py.
All three variants shared an identical C2 protocol using HTTP POST with Base64-encoded JSON payloads, a 60-second beacon interval, and an anachronistic Internet Explorer 8 User-Agent string that serves as a reliable detection indicator in 2026. The RAT supported four command handlers: process termination, in-memory .NET assembly injection (Windows) or binary drops (macOS/Linux), PowerShell or script execution, and directory enumeration. The Windows variant established persistence through a hidden batch file and registry Run key. The Linux variant notably did not persist — likely reflecting an understanding that Linux targets in this context are primarily ephemeral CI/CD runners where credential theft during the build is the objective.
After payload delivery, the dropper performed anti-forensics: deleting itself, replacing its package.json with a clean stub, and leaving the plain-crypto-js directory looking like a normal crypto library. The C2 server at sfrclak[.]com:8000 used POST bodies designed to mimic npm registry traffic (packages.npm.org/product0 through product2) as a SIEM evasion technique.
The compromised maintainer stated he had MFA enabled on his accounts, and the exact method of token compromise remains undetermined. The malicious packages were removed from npm approximately three hours after publication, and the Axios team has since merged a deprecation workflow to formally mark the affected versions.
What Defenders Should Do:
Immediately audit all lockfiles (package-lock.json, yarn.lock, pnpm-lock.yaml) for axios@1.14.1, axios@0.30.4, or any version of plain-crypto-js. The presence of a node_modules/plain-crypto-js directory is sufficient evidence of compromise even if its contents appear clean. Pin to safe versions (axios@1.14.0 or axios@0.30.3) and add overrides to prevent transitive resolution. Check endpoints for platform-specific artifacts: /Library/Caches/com.apple.act.mond on macOS, %PROGRAMDATA%\wt.exe and the MicrosoftUpdate registry key on Windows, and /tmp/ld.py on Linux. Block sfrclak[.]com and 142.11.206.73 on port 8000 at the network perimeter. Any system that executed the payload should be rebuilt from a known-good image, not cleaned in place. Rotate all credentials accessible from affected environments including npm tokens, SSH keys, AWS keys, CI/CD secrets, and API keys. For long-term hardening, always use npm ci instead of npm install in pipelines, enforce --ignore-scripts policies, implement OIDC Trusted Publishing while removing co-existing long-lived tokens, and consider setting npm's min-release-age to enforce a quarantine period on new versions.