⚑ SECURITY ADVISORY ⚑

Axios npm Supply Chain Attack

March 31, 2026 | Cross-Platform RAT via Compromised Maintainer Account | CRITICAL

⚠ ACTIVE THREAT — If you installed axios@1.14.1 or axios@0.30.4, treat your system as fully compromised. Rotate all credentials immediately.

Overview

On March 31, 2026, attackers hijacked the npm account of jasonsaayman, the primary maintainer of the Axios JavaScript HTTP client library. Using stolen credentials, they published two malicious versions (1.14.1 and 0.30.4) containing a hidden dependency that silently installed a cross-platform Remote Access Trojan (RAT) on developer machines and CI/CD systems. The attack was live for approximately three hours before npm removed the packages.

Axios has over 300 million weekly downloads, making this one of the highest-impact supply chain attacks ever attempted against a top-10 npm package.

Attack Timeline

Time (UTC)

Event

Mar 30 – 05:57

Clean plain-crypto-js@4.2.0 published to establish credibility

Mar 30 – 23:59

Malicious plain-crypto-js@4.2.1 (RAT dropper) published

Mar 31 – 00:21

axios@1.14.1 published via compromised jasonsaayman account

Mar 31 – 01:00

axios@0.30.4 published — both branches hit within 39 minutes

Mar 31 – ~03:15

Both malicious Axios versions removed from npm

Mar 31 – 03:25

npm places security hold on plain-crypto-js

Mar 31 – 04:26

Security placeholder package replaces malicious dependency

Technical Details

Account Takeover & CI/CD Bypass

The attacker compromised the npm account of the primary Axios maintainer and changed the registered email to an anonymous ProtonMail address. Critically, the malicious packages were published manually via the npm CLI — completely bypassing the project's normal GitHub Actions CI/CD pipeline. This allowed the attacker to publish without triggering any repository-level controls or release workflows.

The Phantom Dependency

The attacker inserted plain-crypto-js@^4.2.1 into Axios's package.json dependency list. This package is never imported or used anywhere in the Axios source code — its sole purpose was to execute a malicious postinstall hook (setup.js). The package disguised itself as the legitimate crypto-js library by cloning its description, author name, and repository URL.

Dropper Obfuscation

The setup.js dropper used two layers of obfuscation to evade static analysis: reversed Base64 encoding with padding character substitution, and an XOR cipher with the key OrDeR_7077. After execution, it erased itself, deleted the package.json containing the malicious postinstall hook, and replaced it with a clean version — leaving no obvious trace in node_modules upon later inspection.

Cross-Platform RAT Payloads

Three separate OS-specific payloads were pre-built before the attack began, each connecting to a C2 server at sfrclak[.]com:8000:

macOS: Mach-O binary disguised as a system cache file at /Library/Caches/com.apple.act.mond
Windows: PowerShell payload executed via hidden VBScript, persisted as %PROGRAMDATA%\wt.exe
Linux: Python-based backdoor saved to /tmp/ld.py

Self-Destruction & Anti-Forensics

A defining feature of this attack was its emphasis on evasion. Researchers observed a 36-second gap between installation and cleanup — just enough time to establish persistence before erasing all traces. Developers inspecting node_modules afterward would find a completely innocent-looking package.

Affected Versions & Immediate Actions

Affected: axios@1.14.1 and axios@0.30.4. If these versions ran npm install on your system or in your CI/CD pipeline, assume full compromise.

Immediate remediation steps:

Downgrade: Roll back to axios@1.14.0 or axios@0.30.3
Remove: Delete node_modules/plain-crypto-js directory
Reinstall: Run npm install --ignore-scripts
Rotate all credentials: npm tokens, AWS/GCP/Azure keys, SSH private keys, CI/CD secrets, .env file values
Block C2: Add egress block for sfrclak[.]com at firewall/DNS level
Audit pipelines: Review CI/CD build logs for the March 31, 2026 UTC window
Rebuild if necessary: Any system where the RAT executed should be rebuilt from a known-good state

What Would Have Prevented This Attack

Maintainer Account Security

Hardware MFA (FIDO2/Passkey): Phishing-resistant MFA on the npm account was the single most critical missing control — the account takeover was the root cause of the entire attack
npm Trusted Publishing / Provenance Attestation: Requiring all publishes to originate from a verified GitHub Actions workflow would have blocked the manual CLI publish entirely
Immutable release signing: Cryptographic signing tied to CI/CD would have made unauthorized publishes verifiable and detectable

Dependency & Build Hygiene

--ignore-scripts as CI/CD default: Prevents postinstall scripts from executing automatically during npm install — this single flag would have neutralized the attack vector
Lockfile pinning: Committing package-lock.json and pinning to exact versions prevents unexpected new versions from being pulled in CI/CD
Phantom dependency detection: Automated tooling that alerts when a new transitive dependency appears that is not imported in the codebase would have flagged plain-crypto-js immediately
Dependency review on PRs: Policy checks that block merges when unexpected new dependencies are introduced

Runtime & Network Controls

Egress filtering in CI/CD: Blocking unknown outbound connections from build environments would have prevented the RAT from phoning home to sfrclak[.]com even if installed
SCA / supply chain scanning: Tools like Snyk, Socket, and StepSecurity analyze dependency trees for anomalies, known-malicious packages, and behavioral indicators in real time
Endpoint detection in build agents: EDR coverage of CI/CD runners would detect the dropper's execution, persistence mechanisms, and outbound C2 connection

Process Controls

Separation of duties for package publishing: Requiring multi-party approval for new package versions of critical libraries
Version bump notifications: Out-of-band alerts to maintainer teams when a new version is published, allowing rapid detection of unauthorized publishes
Credential rotation policy: Regular rotation of npm publish tokens limits the window of exposure from stolen credentials

MITRE ATT&CK Mapping

This attack maps to the following MITRE ATT&CK techniques:

T1195.001 — Supply Chain Compromise: Development Tools: Injecting malicious code into widely used open-source libraries
T1078 — Valid Accounts: Using compromised legitimate maintainer credentials to publish packages
T1059 — Command and Scripting Interpreter: PowerShell (Windows), AppleScript (macOS), Python (Linux) for payload execution
T1027 — Obfuscated Files or Information: Double-layer obfuscation (XOR + reversed Base64) in the dropper
T1070 — Indicator Removal: Self-deletion of dropper and malicious package.json post-execution

Final Thoughts

Here yet another compromise with a root cause not tied to a zero day but rather exploitation of weak authentication / authorization controls. The attack could have been completely thwarted with the simple implementation of hardware MFA - a $50 expense per user and configured in less than 15 minutes. These kinds of exploits are symptomatic of an industry that chases shiny new tools and overlooks the mundane basic configuration best practices that harden organizations against these very types of attacks. At the end of the day, this attack should never have happened.

References & Further Reading

Snyk: Axios npm Package Compromised — Supply Chain Attack Delivers Cross-Platform RAT

The Hacker News: Axios Supply Chain Attack Pushes Cross-Platform RAT via Compromised npm Account

OX Security: Axios Compromised With A Malicious Dependency

Cyber Express: Axios Supply Chain Attack Exposes Malicious Npm Packages

Techzine: Axios npm package compromised, posing a new supply chain threat

Cyber Insider: Axios Supply Chain Attack Hits Library with 400M Monthly Downloads

Cybernews: Hackers hit axios, a hugely popular NPM library with 100M downloads

Prepared March 31, 2026 | Intelligence sourced from Socket, Snyk, StepSecurity, OX Security, and Huntress