The Axios NPM Supply Chain Attack: What We Know, What’s Assumed & the Fallout

⚠ Active Incident Published: March 31, 2026

Category: Supply Chain Security

Severity: Critical

🚨 Immediate Action Required If your environment ran npm install on axios between 00:21 UTC and 03:29 UTC on March 31, 2026, you may have deployed a Remote Access Trojan. Treat affected systems as fully compromised — do not attempt to clean in place. Rebuild from a known-good state and rotate all credentials.

Background: Why Axios Is a Big Target

Axios is the de facto standard HTTP client for JavaScript. It runs in browsers, Node.js backends, serverless functions, CI/CD pipelines, mobile apps via React Native, and virtually every modern cloud environment. With somewhere between 83 and 300 million weekly downloads, it is one of the top ten most downloaded packages on the entire npm registry — present in roughly 80% of cloud and code environments globally.

That scale is exactly what made it a high-value target. A brief window of compromise on a package this embedded doesn’t require thousands of victims — the math works in the attacker’s favor from the first minute the poisoned version is live.

What We Know (Confirmed)

The Attack Timeline

Mar 30
05:57 UTC

Stage 1 — Clean Decoy Publishednpm user nrwise@proton.me publishes plain-crypto-js@4.2.0 — a clean copy of the legitimate crypto-js library. Its purpose: establish a brief publishing history so later versions wouldn’t appear zero-history to security scanners.

Mar 30
23:59 UTC

Stage 2 — Malicious Payload Activatedplain-crypto-js@4.2.1 is published containing a postinstall hook pointing to an obfuscated dropper script (setup.js). Socket’s automated scanner flags it within 6 minutes.

Mar 31
00:21 UTC

Stage 3 — Axios 1.x Poisonedaxios@1.14.1 is published from the compromised jasonsaayman account (email changed to ifstap@proton.me). The only change from the legitimate release: plain-crypto-js@4.2.1 added as a runtime dependency. No axios source code was touched. No corresponding GitHub tag exists.

Mar 31
01:00 UTC

Stage 4 — Axios 0.x Also Poisonedaxios@0.30.4 is published via the same compromised account — poisoning the legacy 0.x branch just 39 minutes after the 1.x release.

Mar 31
~03:15 UTC

Stage 5 — npm Removes Malicious VersionsBoth axios@1.14.1 and axios@0.30.4 are unpublished. The latest tag reverts to 1.14.0. The malicious versions were live for approximately 2h 53m and 2h 15m respectively.

Mar 31
04:26 UTC

Stage 6 — plain-crypto-js Tombstonednpm publishes a security-holder stub (plain-crypto-js@0.0.1-security.0). Any attempt to install any version of plain-crypto-js now returns a security notice.

How the Dropper Works

The malicious setup.js dropper (4,209 bytes) fires automatically via npm’s postinstall lifecycle hook the moment npm install runs. It uses two layers of obfuscation to defeat static analysis: reversed Base64 encoding with padding character substitution, then an XOR cipher with the key OrDeR_7077 and a constant of 333.

Once decoded, the dropper fingerprints the OS, phones home to the attacker’s C2 server at sfrclak.com:8000, retrieves a platform-specific second-stage payload, executes it, then self-destructs — deleting setup.js and replacing its own package.json with a clean decoy. The entire process takes approximately 15 seconds. A developer inspecting node_modules afterward finds no obvious sign anything happened.

Platform-Specific RAT Payloads

macOS: RAT artifact dropped at:
/Library/Caches/com.apple.act.mond

Windows: RAT artifact dropped at:
%PROGRAMDATA%\wt.exe

Linux: RAT artifact dropped at:
/tmp/ld.py

What Systems Were Exposed

Environment Type	Exposure Vector	Risk Level
Developer workstations	Manual npm install or update during the window	Critical
CI/CD pipelines	Automated builds using caret ranges (^1.14.0) re-resolving	Critical
Docker build environments	RUN npm install in Dockerfiles without pinned lockfiles	Critical
Cloud / serverless build runners	Fresh installs on ephemeral workers during the window	High
Projects using caret ranges	^1.14.0 or ^0.30.0 auto-resolve to malicious version	High
Transitive consumers	@shadanai/openclaw and @qqbrowser/openclaw-qbot ship poisoned axios	Medium

Wiz Security observed actual RAT execution in approximately 3% of affected environments — meaningful at this scale.

What’s Being Assumed (Unconfirmed)

How the Account Was Compromised

Early maintainer statements and community discussion point to a likely combination of a long-lived npm token that was never rotated and insufficient use of Granular Access Tokens and trusted publishing controls. The attacker changed the account’s registered email to ifstap@proton.me before publishing, locking out the legitimate owner. The exact initial access vector — phishing, credential stuffing, or a leaked token — has not been publicly confirmed.

Attacker Attribution and Motive

No group has claimed responsibility as of publication. The operational sophistication — pre-staging a dependency 18 hours in advance, building three platform-specific payloads, implementing anti-forensic self-deletion, and poisoning both release branches within 39 minutes — suggests a well-resourced actor. Some researchers have noted similarities to the TeamPCP campaign that targeted Trivy, LiteLLM, and Telnyx just days prior, though a direct link has not been confirmed.

Full Scope of the RAT’s Capabilities

The second-stage payload’s full capability set is still under analysis. What the RAT does post-installation — keylogging, credential harvesting, lateral movement, persistent access — remains under active investigation by multiple security firms.

Current Aftermath & Status

Active / Developing

The malicious versions were removed from npm within roughly three hours. The legitimate axios@1.14.0 is clean and is the current recommended version. The primary maintainer has issued a public statement confirming the account compromise, with remediation efforts underway including token revocation and pipeline hardening.

Additional poisoned packages have been identified: @shadanai/openclaw (versions 2026.3.28-2, -3, 2026.3.31-1, -2) and @qqbrowser/openclaw-qbot@0.0.130. Security identifiers: GHSA-fw8c-xr5c-95f9 and MAL-2026-2306.

How to Detect If You Were Compromised

Step 1 — Check Your Dependency Tree

# Check lockfiles for the malicious dependencygrep -r “plain-crypto-js” ./package-lock.jsongrep -r “plain-crypto-js” ./yarn.lock# Check node_modules (presence means dropper ran)ls node_modules/plain-crypto-js# Confirm axios versioncat node_modules/axios/package.json | grep ‘”version”‘# BAD: “version”: “1.14.1” or “version”: “0.30.4”# GOOD: “version”: “1.14.0” or prior clean release

Step 2 — Hunt for RAT Artifacts by OS

# macOSls -la /Library/Caches/com.apple.act.mond# Windows (PowerShell)Test-Path “$env:PROGRAMDATA\wt.exe”# Linuxls -la /tmp/ld.py

Step 3 — Audit CI/CD Build Logs

Review pipeline logs for the window of 00:21–03:29 UTC on March 31, 2026. Any build that resolved axios@1.14.1 or axios@0.30.4 should have its runner and all accessed secrets treated as compromised.

Step 4 — Search Network Logs for C2 Callbacks

Search DNS, proxy, and firewall logs for outbound connections to sfrclak.com or sfrclak.com:8000. Any hit confirms RAT execution.

⚠ Important Note on Self-Deletion The dropper self-destructs after execution. The absence of plain-crypto-js in your node_modules does not mean you are safe. If your lockfile or build logs show it was installed during the exposure window, assume compromise regardless of current file system state.

Remediation Steps

• Pin axios to 1.14.0 in package.json and regenerate your lockfile
• Run npm audit — check for GHSA-fw8c-xr5c-95f9 or SNYK-JS-PLAINCRYPTOJS-15850652
• If a RAT artifact is found — rebuild from a known-good state. Do not clean in place
• Rotate all credentials accessible from the compromised environment: npm tokens, AWS/GCP/Azure keys, SSH private keys, CI/CD secrets, .env values
• Audit Docker images built during the exposure window and repromote from a clean base
• Block sfrclak.com at the firewall/DNS level and alert on any historical hits
• Move to Granular Access Tokens on npm, enable 2FA enforcement, and implement trusted publishing via CI rather than personal long-lived tokens

Indicators of Compromise (IOC Summary)

Type	Indicator	Description
Package	axios@1.14.1	Malicious npm release — 1.x branch
Package	axios@0.30.4	Malicious npm release — 0.x branch
Package	plain-crypto-js@4.2.1	Malicious dropper dependency
Domain	sfrclak.com	C2 command-and-control server
Port	:8000	C2 callback port
File (macOS)	/Library/Caches/com.apple.act.mond	Dropped RAT artifact
File (Windows)	%PROGRAMDATA%\wt.exe	Dropped RAT artifact
File (Linux)	/tmp/ld.py	Dropped Python RAT
npm Account	jasonsaayman / ifstap@proton.me	Compromised publisher identity
npm Account	nrwise@proton.me	Created malicious dependency
GHSA	GHSA-fw8c-xr5c-95f9	GitHub Security Advisory ID
MAL ID	MAL-2026-2306	Malware registry identifier

The Bigger Picture

This attack follows a pattern that has accelerated over the past 18 months: compromise a legitimate maintainer credential, publish a minimal change that doesn’t touch source code, and rely on the ecosystem’s implicit trust of registered packages. What sets this incident apart is the operational precision — pre-staging, dual-branch poisoning, triple-OS payload delivery, and anti-forensic self-deletion. A roughly three-hour window still produced confirmed RAT execution in approximately 3% of observed affected environments.

For defenders, this is a strong argument for lockfile-based installs (npm ci over npm install), npm provenance attestation, runtime egress monitoring on build runners, and mandatory MFA with token rotation policies for any npm publisher account tied to a high-download package.

References & Further Reading: How to Detect and Protect Against CVE-2026-20952 and CVE-2026-20953, CVE-2026-2441: Google Chrome CSS Use-After-Free Zero-Day

#SupplyChain#npm#Axios#RAT#SOC#IncidentResponse