axios Backdoored on npm: Compromised Maintainer Account Delivers Cross-Platform RAT to 40M+ Weekly Downloads

March 31, 2026 | Phoenix Security Vulnerability Intelligence | Supply Chain Incident Report

Executive Summary

On March 31, 2026, two malicious versions of axios were published to npm. The attack compromised the account of jasonsaayman — the primary axios maintainer — changed the account email to an attacker-controlled ProtonMail address, and used stolen credentials to publish axios@1.14.1 and axios@0.30.4 directly via the npm CLI, bypassing the project’s GitHub Actions OIDC-signed CI/CD pipeline entirely.

Neither version contains a single malicious line inside axios itself. Instead, both inject a phantom dependency — plain-crypto-js@4.2.1 — a package that is never imported anywhere in the axios source code. Its only purpose is to execute a postinstall hook that deploys a fully featured, cross-platform remote access trojan within 15 seconds of npm install running. The RAT targets Windows, Linux, and macOS with platform-specific second-stage payloads, encrypts harvested credentials with AES-256-CBC and RSA-4096, and exfiltrates to a live C2 server at sfrclak.com:8000.

With over 300 million weekly npm downloads, axios is present in virtually every JavaScript codebase that makes HTTP requests — from React frontends to CI/CD tooling to production server APIs. The campaign’s blast radius extends far beyond development machines: any CI/CD pipeline that ran npm install during the 3-hour 19-minute exposure window should treat all injected secrets as compromised. No CVE has been assigned. Traditional CVE-based scanners will not flag it.

Malware has been taken down.

TL;DR for Engineering Teams

Vulnerability Overview

Technical Anatomy

Phase 1: Maintainer Account Hijack and Pre-Staging

The attack was staged across roughly 24 hours before the poisoned axios releases appeared. On March 30 at 05:57 UTC, an attacker-controlled account (nrwise, registered nrwise@proton.me) published plain-crypto-js@4.2.0 — a clean decoy containing a full copy of the legitimate crypto-js source with no postinstall hook. This established npm publishing history so the package would not trigger zero-history alerts from automated scanners.

This from the original discussion perfectly sums how we all feel.

Seventeen hours later at 23:59 UTC, plain-crypto-js@4.2.1 was published from the same account — this time with the malicious postinstall hook and obfuscated dropper (setup.js) added. The attacker then used compromised credentials for jasonsaayman to publish the backdoored axios releases. The account email had been changed to ifstap@proton.me. Both attacker accounts used ProtonMail: a consistent operational pattern.

Critical forensic signal: Every legitimate axios 1.x release since adopting Trusted Publishers carries an OIDC token binding it cryptographically to a specific GitHub Actions workflow. axios@1.14.1 carries no such binding, no gitHead, and no corresponding commit or tag in the GitHub repository. The release exists only on npm. This is the single most reliable detection indicator for the compromise.

Phase 2: The Phantom Dependency Injection

The surgical diff between clean and compromised versions is one line in package.json — the addition of plain-crypto-js: "^4.2.1" as a runtime dependency. This package is never imported, required, or referenced anywhere in the axios source code across all 86 files. Its presence in package.json exists solely to trigger npm’s dependency resolution and execute the postinstall hook.

When a developer runs npm install axios@1.14.1, npm automatically resolves the dependency tree, installs plain-crypto-js@4.2.1, and executes its postinstall script: node setup.js. The hook fires before npm returns control to the terminal. From the developer’s perspective, npm install completed successfully. The backdoor has already run.

The Obfuscated Dropper: setup.js

setup.js is a single minified file using a two-layer obfuscation scheme. All sensitive strings are stored as encoded values in an array (stq[]) and decoded at runtime:

• Layer 1 — XOR cipher: The key "OrDeR_7077" is parsed through Number(), which coerces alphabetic characters to NaN. In bitwise operations NaN becomes 0, leaving only the digits [7,0,7,7] effective at positions 6–9. Each character at position r is decoded as: charCode XOR key[(7 × r × r) % 10] XOR 333
• Layer 2 — Outer wrapper: Reverses the encoded string, substitutes underscores for equals signs (base64 padding), base64-decodes, then passes through the XOR cipher

Once decoded, the full C2 URL is: http://sfrclak.com:8000/6202033. The path segment 6202033 is the campaign identifier. After launching the platform-specific payload, setup.js performs three evidence-destruction steps: deletes itself (fs.unlink(__filename)), deletes the real package.json, and renames a pre-staged clean stub (package.md) to package.json. Any post-infection inspection of node_modules/plain-crypto-js/ shows a clean manifest with no postinstall hook.

The directory node_modules/plain-crypto-js/ remaining on disk — even with a clean-looking package.json — is sufficient evidence the dropper executed. axios has no legitimate dependency with this name.

Stage 1: Platform Detection and Payload Delivery

The dropper detects os.platform() and branches into three attack paths. Each sends a distinct POST body to the same C2 URL, allowing the server to return the appropriate second-stage payload. The packages.npm.org/ prefix in the POST body is deliberate — it makes C2 traffic look like routine npm registry communication in network logs.

Stage 2: Credential Harvesting

The RAT performs a systematic, exhaustive sweep of the compromised host. On Windows, the PowerShell payload establishes persistence via a HKCU Run registry key named MicrosoftUpdate pointing to %PROGRAMDATA%\system.bat, then uses reflective .NET assembly injection to load the stage-2 binary directly into memory without touching disk. On macOS, the native Mach-O universal binary (supporting both x86_64 and arm64) is deployed to /Library/Caches/com.apple.act.mond — a path mimicking legitimate Apple system cache naming conventions.

Credential categories swept across all platforms:

Stage 3: Encrypted Exfiltration and C2 Persistence

Collected data is encrypted with AES-256-CBC (key derived via PBKDF2 from 32 random bytes), with the session key wrapped using a hardcoded RSA-4096 public key (OAEP padding). The bundle is packaged as tpcp.tar.gz and POSTed via HTTPS to sfrclak.com:8000/6202033 with header X-Filename: tpcp.tar.gz. Only the holder of the RSA private key can decrypt the bundle.

After the initial exfiltration, the RAT beacons back to C2 every 60 seconds with BaseInfo payloads containing hostname, username, OS version, timezone, hardware fingerprint, and a full process list. The process list reveals running security tools (EDR, AV, monitoring), active development environments, other potential pivot targets on the same host, and which debugging or orchestration tools are active.

Runtime Validation: What Actually Happened

StepSecurity’s Harden-Runner instrumentation confirmed the exact execution chain:

• C2 contact occurs 1.1 seconds into npm install — before npm has finished resolving all dependencies
• A second C2 connection fires 36 seconds later, in a completely separate workflow step after npm install has exited, confirming the detached background process survived beyond the installing step
• Both connections show calledBy: "infra" rather than "runner" because the malware used nohup ... & to orphan itself to PID 1
• The package.json overwrite is captured as two writes from two separate PIDs, 36 seconds apart — confirming the evidence swap

The process tree: npm install → sh → node setup.js → sh → curl/nohup. Four levels of indirection from installation to C2 callback.

Affected Versions

axios (This Compromise)

SHA Verification for Safe Versions

Discovery and Disclosure Timeline

Determine If You’re Affected

Exposure by Environment

Verification Commands

Run these on any potentially affected machine or in CI artifact inspection:

# Check for compromised axios versions
npm list axios 2>/dev/null | grep -E '1\.14\.1|0\.30\.4'
grep -A1 '"axios"' package-lock.json | grep -E '1\.14\.1|0\.30\.4'

# Check for dropper evidence (directory presence = payload ran)
ls node_modules/plain-crypto-js 2>/dev/null && echo 'DROPPER RAN'

# macOS: check for persistent RAT binary
ls -la /Library/Caches/com.apple.act.mond 2>/dev/null && echo 'COMPROMISED'

# Linux: check for Python RAT
ls -la /tmp/ld.py 2>/dev/null && echo 'COMPROMISED'

# Windows (cmd.exe)
dir "%PROGRAMDATA%\wt.exe" 2>nul && echo COMPROMISED

# Check for OIDC provenance (absence = manual/malicious publish)
npm view axios@1.14.1 dist.attestations 2>/dev/null || echo 'NO PROVENANCE ATTESTATION'

Detection Guidance

Indicators of Compromise

File Hashes (SHA-256 and npm shasum)

MITRE ATT&CK Mapping

Temporary Protections

Immediate Actions — Do This Now

1. Downgrade axios and pin the safe version:

npm install axios@1.14.0  # 1.x users
npm install axios@0.30.3  # 0.x users

2. Add overrides to prevent transitive resolution:

{
  "overrides": { "axios": "1.14.0" },
  "resolutions":  { "axios": "1.14.0" }
}

3. Remove plain-crypto-js and reinstall with scripts disabled:

rm -rf node_modules/plain-crypto-js
npm install --ignore-scripts

4. Block C2 at network/DNS level:

# Linux firewall
iptables -A OUTPUT -d 142.11.206.73 -j DROP
echo '0.0.0.0 sfrclak.com' >> /etc/hosts

5. Kill running RAT processes and remove persistence:

# macOS
pkill -f com.apple.act.mond && rm -f /Library/Caches/com.apple.act.mond
# Linux
pkill -f ld.py && rm -f /tmp/ld.py
# Windows
Remove-ItemProperty -Path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Run' -Name 'MicrosoftUpdate'
Remove-Item "$env:PROGRAMDATA\wt.exe" -Force

6. Rotate all credentials on affected machines: GitHub tokens, AWS/GCP/Azure credentials, SSH keys, npm tokens, Docker registry credentials, Kubernetes secrets, Vault tokens, .env files, and anything in shell history.
7. Audit CI/CD pipeline run logs for any npm install that executed during 00:21–03:40 UTC March 31. Any pipeline that installed axios@1.14.1 or axios@0.30.4 must have all injected secrets rotated.

Long-Term Hardening

• Use npm ci –ignore-scripts in all CI/CD pipelines as a standing policy. Postinstall hooks are the primary delivery vector for npm supply chain attacks.
• Verify OIDC provenance attestation on packages from projects that publish via GitHub Actions. The absence of provenance on a new release from a previously OIDC-enabled project is a high-signal indicator of account compromise.
• Enable StepSecurity Harden-Runner or equivalent CI egress filtering. An allowlisted network policy would have blocked the C2 callback before any credentials left the runner.
• Add npm Package Cooldown checks to your CI pipeline. Most malicious npm packages are identified within 24 hours of publication; a configurable hold on newly published versions provides a meaningful detection window without blocking critical updates.
• Monitor npm registry metadata changes for packages your organisation depends on. A change in the publisher field from “GitHub Actions” to a human account name is immediately suspicious for projects using Trusted Publishers.
• Consider using a private npm registry proxy with package mirroring and a quarantine policy for newly published versions of high-impact dependencies.

Real-World Impact

axios is not a niche utility. It is the default HTTP client for JavaScript. React applications, Express APIs, Next.js backends, CLI tools, and CI/CD automation — virtually every Node.js project that communicates over HTTP has axios in its dependency tree. The npm registry records over 300 million weekly downloads. A 3-hour 19-minute exposure window against that install base means the potential exposure count runs into the tens of thousands of environments.

The targeting is deliberately broad but the intelligence value is specific: developer machines carry SSH keys, cloud credentials, and access to production environments that no endpoint on the public internet can directly reach. A compromised developer workstation is a pre-authenticated foothold inside the perimeter. CI/CD runners carry the most valuable credentials in the organisation — deployment tokens, cloud IAM credentials, registry credentials, and API keys for every downstream service the pipeline touches.

The attack generated no CVE, no CVSS score, and no NVD entry. Traditional CVE-based vulnerability management workflows would not have detected it. Organizations running SCA tools that exclusively scan for known CVEs had zero automated visibility into this compromise during the exposure window.

This is a good conclusion of the discussion.

Phoenix Security Recommendations

The axios compromise is proof that the attack surface for software supply chain threats extends far beyond the CVE feed. This campaign had no vulnerability identifier, no patch, and no CVE-based detection signal. The compromised package was one of the most trusted libraries in the JavaScript ecosystem. If your vulnerability management programme only flags known CVEs, this attack was invisible to it from start to finish.

Attack surface management: Phoenix identifies which environments have axios installed and cross-references installed versions against the known-compromised 1.14.1 and 0.30.4 releases.

Contextual deduplication: Organisations running axios across dozens of services get a single prioritised remediation backlog rather than duplicate alerts per repo.

Reachability analysis: Phoenix distinguishes between environments where axios@1.14.1 was installed and where it actually executed during the 3-hour exposure window.

Remediation campaigns: Create a campaign in Phoenix to track completion of version downgrades, lock-file pinning, plain-crypto-js removal, persistent-artifact cleanup, and credential rotation across all affected environments.

Ownership attribution: Map each affected service to the owning team. Phoenix automates that mapping, turning a cross-organisation incident into an owned, trackable remediation backlog.

References

1. 6mile — Dissecting a Sophisticated NPM Supply Chain Attack: The axios + plain-crypto-js Malware Campaign (March 31, 2026)
2. StepSecurity — axios Compromised on npm: Malicious Versions Drop Remote Access Trojan (ashishkurmi, March 31, 2026)
3. axios GitHub Issue #10604 — Community tracking of compromise
4. npm Registry — axios version history and publisher metadata
5. StepSecurity Harden-Runner — Runtime validation run
6. Wiz Research — Trivy Compromised by TeamPCP — upstream campaign context
7. Socket Security — CanisterWorm: npm Publisher Compromise Deploys Backdoor Across 29 Packages

How Phoenix Security Fixes What Actually Matters

Your team doesn’t have a finding problem. They have a fixing problem.

Most platforms hand you a list. Phoenix hands you a plan — ranked by real risk, mapped to the team that owns it, with a clear path to close it.

What remediation looks like with Phoenix:

• One backlog, not five. Findings from SAST, SCA, containers, and cloud — deduplicated, correlated, and surfaced in a single prioritized queue. No more reconciling lists across tools.
• Ownership that sticks. Team attribution and inheritance mean the right ticket goes to the right engineer, first time. No routing, no guessing, no back-and-forth.
• Campaigns that move the needle. Group related findings into targeted remediation campaigns. Track progress, measure closure rates, and report real reduction — not raw counts.
• AI that does the legwork, not the deciding. Phoenix’s Remediator agent drafts fixes, creates tickets, and opens PRs. Your team reviews, approves, and merges. Every fix is traceable.

Phoenix Security changes the game.

The results are clear:

• Bazaarvoice saved $6.3M in developer time and for teams removed critical in the first weeks of adoption
• ClearBank cut critical container vulnerabilities by 96–99% and reclaimed 4 hours per engineer per week.
• IAS saved an equivalent of 1.5M in development hours and reduced SCA-to-container noise by 82.4%
• Optimizely has been able to act on vulnerabilities sitting on the backlog.

The pattern is the same every time: teams that move from find and report to analyze and fix close more risk with less effort.

The results are clear:

• Bazaarvoice saved $6.3M in developer time and for teams removed critical in the first weeks of adoption
• ClearBank cut critical container vulnerabilities by 96–99% and reclaimed 4 hours per engineer per week.
• IAS saved an equivalent of 1.5M in development hours and reduced SCA-to-container noise by 82.4%
• Optimizely has been able to act on vulnerabilities sitting on the backlog.

👉 Book a demo today

Or learn how Phoenix Security slashed millions in wasted dev time for fintech, retail, and adtech leaders.

Fix with remediaiton don’t chase ghost vulnerabilities

Get Fixing today