Axios npm Supply Chain Attack: 83M Weekly Downloads Compromised by Cross-Platform RAT

On March 31, 2026, threat actors successfully compromised the npm account of a lead maintainer of the axios HTTP client library and published two backdoored versions: axios@1.14.1 and axios@0.30.4. With approximately 83 million weekly downloads and over 2 million dependent packages, this is among the most consequential software supply chain attacks ever recorded against the JavaScript ecosystem.

The compromised versions injected a malicious dependency called plain-crypto-js that deployed a cross-platform Remote Access Trojan (RAT) targeting macOS, Windows, and Linux systems simultaneously. The attack was first publicly flagged by security researcher @mvxvvll on X, and Elastic Security researcher Joe Desimone published a detailed technical analysis of the payload mechanics. StepSecurity's behavioral monitoring system detected the anomalous release within 14 minutes.

What Happened: The Attack Timeline

The incident unfolded in a tight 39-minute window. At approximately 00:00 UTC on March 31, the attacker gained control of the primary maintainer's npm account and immediately changed the registered email address to an anonymous ProtonMail account. This redirected all npm notifications away from the legitimate maintainer and extended the attacker's window of operation.

At 00:21 UTC, axios@1.14.1 was published to npm with the latest dist-tag. Roughly 39 minutes later, axios@0.30.4 followed with the legacy dist-tag, targeting organizations still running the 0.x branch. Both versions contained a single addition to package.json: a runtime dependency on plain-crypto-js, a package that had been pre-staged 18 hours earlier by a separate throwaway account.

Critically, the malicious versions were published via direct npm CLI commands, bypassing the project's normal GitHub Actions CI/CD pipeline. Legitimate axios releases are published with OIDC-backed SLSA provenance via GitHub Actions. The absence of provenance attestation on these releases is a key detection signal, and one that automated tooling should flag.

How the Payload Works

The plain-crypto-js package was deliberately designed to look legitimate. It masqueraded as the popular crypto-js library, replicating its description, author attribution, and repository URL. Its only functional purpose was a postinstall script (setup.js) that served as the dropper for a cross-platform RAT.

The dropper used a two-layer obfuscation scheme. An array of 18 command strings was first reversed and Base64-encoded, then XOR-encrypted with the key OrDeR_7077 using an index formula to derive per-character XOR operands. Once decoded at runtime, the script detected the host operating system and executed platform-specific payload delivery.

On macOS, the dropper used AppleScript to download a stage-2 binary from the attacker's command-and-control server and install it at /Library/Caches/com.apple.act.mond, disguised as an Apple system cache file. On Windows, it copied PowerShell to %PROGRAMDATA%\wt.exe (masquerading as Windows Terminal), dropped a VBScript launcher and PowerShell payload, then executed silently with hidden windows. On Linux, a Python script was downloaded to /tmp/ld.py (disguised as the system linker) and run in the background using nohup.

All stage-2 payloads were downloaded from the same C2 infrastructure at sfrclak.com (142.11.206.73) on port 8000 over plain HTTP. The use of unencrypted HTTP with no TLS, a single server with no CDN or domain fronting, and a freshly registered domain with privacy-protected WHOIS all suggest a speed-over-stealth operational approach more consistent with a financially motivated actor than a nation-state APT.

Anti-Forensics: Designed to Disappear

What makes this attack operationally sophisticated is not just the payload delivery but the cleanup mechanisms built into every step. The setup.js dropper self-deleted after execution using fs.unlinkSync. A file named package.md, byte-identical to the clean version of package.json, was used to overwrite the malicious package.json post-execution, erasing the evidence of the injected dependency. On Windows, both the VBScript and PowerShell payloads self-deleted after running.

On macOS, the attack used the Apple Events scripting layer (osascript) instead of direct exec(), which breaks the process ancestry chain and makes it harder for process monitoring tools to trace the RAT back to the npm install. On Windows, PowerShell was run with -WindowStyle Hidden and VBScript with visibility set to zero, keeping the entire execution invisible to the user.

Detection Guidance

Security teams should immediately audit their environments using these approaches:

Package scanning: Run npm ls plain-crypto-js --all --depth=Infinity across all Node.js projects. Check package-lock.json for entries referencing axios@1.14.1 or axios@0.30.4. Run npm audit and clear the npm cache with npm cache clean --force.

Network monitoring: Block the domain sfrclak.com and IP 142.11.206.73 (port 8000) at all egress points. Review firewall and proxy logs for any outbound connections to these indicators over the past 48 hours. Deploy Suricata or Snort rules that alert on HTTP traffic to this C2 infrastructure.

Filesystem hunting: On macOS, check for /Library/Caches/com.apple.act.mond and LaunchDaemon persistence entries. On Windows, look for %PROGRAMDATA%\wt.exe, %TEMP%\6202033.vbs, and %TEMP%\6202033.ps1. On Linux, check for /tmp/ld.py and any running python3 /tmp/ld.py processes.

Remediation Steps

If your organization ran npm install between 00:21 UTC on March 31 and the time the malicious versions were removed from the registry, you should treat affected systems as compromised until investigated. The immediate actions are threefold: block the C2 at all network egress, pin axios to the safe versions (1.14.0 for the 1.x branch or 0.30.3 for the 0.x branch), and rotate all developer credentials on any potentially affected system, including npm tokens, GitHub PATs, SSH keys, and cloud API keys.

In the short term, rebuild CI/CD environments from clean base images, enforce npm ci (not npm install) with committed lockfiles, and audit all Docker images built after the incident window. Longer term, this incident reinforces the need for npm provenance verification, Software Bill of Materials (SBOM) generation, and continuous dependency monitoring through SCA and SBOM tooling.

Blast Radius: Why This Attack Stands Apart

To put the scale in perspective: the 2021 ua-parser-js attack, which is widely considered a landmark supply chain incident, affected a package with approximately 7 million weekly downloads. The axios attack, at roughly 83 million weekly downloads, represents about 12 times greater potential reach. Both the latest and legacy release branches were targeted within 39 minutes, meaning organizations on either the 1.x or 0.x line were exposed.

The risk is particularly acute for CI/CD pipelines that run npm install without pinned lockfiles, developer workstations where packages are installed directly, and Docker images built during the exposure window. Any environment that auto-resolved the latest or legacy dist-tag during that window received the backdoored version.

Broader Context: Supply Chain Attacks Are Accelerating

This incident does not exist in isolation. The JavaScript and open-source ecosystems have faced a sustained escalation of supply chain attacks. The Shai-Hulud worm campaign in September 2025 infected over 500 npm packages and led to a CISA advisory. The xz-utils backdoor in March 2024 demonstrated how social engineering of maintainers could compromise critical infrastructure. More recently in March 2026, the TeamPCP campaign weaponized 76 Trivy version tags, and a separate "Ghost Campaign" targeted crypto wallet credentials through seven malicious npm packages.

The common thread across all of these incidents is the exploitation of trust: trust in maintainer accounts, trust in automated pipelines, and trust in the dependency resolution process itself. Organizations that rely on periodic vulnerability scanning alone are structurally unable to detect these attacks, because the malicious code arrives through legitimate channels and often self-destructs before traditional scanners can catch it.

This is precisely why a Continuous Threat Exposure Management (CTEM) approach is necessary. CTEM shifts the paradigm from reactive scanning to continuous monitoring, adversarial validation, and real-time response across the entire attack surface, including the software supply chain.

How Strobes AI Responded to This Incident in Real Time

When the axios compromise was identified, the Strobes CTEM platform activated its AI-powered incident response workflow to conduct parallel analysis across all customer-monitored assets. The platform launched multiple specialized agents simultaneously, each handling a distinct aspect of the investigation.

A Threat Intel Agent performed threat intelligence enrichment on the axios npm indicators, correlating the compromised package versions, C2 infrastructure, and payload hashes against known threat feeds and the platform's internal knowledge base. A Code Review Agent conducted deep malware analysis of the plain-crypto-js dropper, deobfuscating the XOR-encrypted command strings and mapping the complete delivery chain across all three target platforms. An Exposure Assessment Agent evaluated every asset registered in the customer's Strobes environment, determining which systems had Node.js stacks, which were likely to have run npm install during the exposure window, and which environments had lockfile enforcement that may have provided protection.

All three agents completed their analysis concurrently using Claude Sonnet 4.6 as the reasoning backbone, collectively leveraging over 78 tools and producing a comprehensive incident response report with prioritized remediation actions, IOC tables, YARA rules, Suricata signatures, and a MITRE ATT&CK mapping of the entire attack chain. The platform then created structured tasks for the remediation team, automatically prioritized by asset criticality and exposure confidence.

This is what outcome-driven security looks like in practice: not just detecting the vulnerability, but understanding the exposure, validating the risk, and driving remediation, all within the first hours of a zero-day supply chain incident.

Key Takeaways

• Pin your dependencies using exact versions and committed lockfiles. Always use npm ci in CI/CD pipelines, never npm install without a lockfile.
• Verify npm provenance on critical packages. Legitimate axios releases include OIDC/SLSA attestation via GitHub Actions; the malicious versions did not.
• Enforce MFA on all npm maintainer accounts, preferably hardware keys (FIDO2) rather than TOTP.
• Generate and maintain SBOMs for all production deployments so you can determine exposure within minutes when the next supply chain incident occurs.
• Adopt continuous supply chain monitoring through tools like StepSecurity, Socket.dev, or integrated CTEM platforms that correlate package changes with real-time threat intelligence.
• Block the C2 indicators immediately: sfrclak.com, 142.11.206.73, port 8000, URL path /6202033.

Credit: This analysis draws on research by Joe Desimone of Elastic Security, the initial public disclosure by @mvxvvll, detailed technical reporting by StepSecurity and Socket.dev, and incident response analysis performed by the Strobes Security platform.