Axios Supply Chain Attack (Technical Guide)

Axios Supply Chain Attack (Technical Guide)

1. What Are Supply Chain Attacks?

Imagine you’re building a house. Instead of breaking into your finished house, a thief sneaks into the factory that makes your bricks or nails and swaps them for defective (or booby-trapped) ones. When you build with those “trusted” materials, your house gets infected automatically.

In software, a supply chain attack does exactly that. Attackers don’t hack your app directly. They compromise a popular library or tool that thousands of projects depend on (like a package on npm, PyPI, etc.). When you run npm install, the malicious code slips in silently.

This is one of the most dangerous attacks because:

  • The package looks completely legitimate.
  • It affects everyone who uses the library (even indirectly as a “nested” dependency).
  • It often runs automatically during installation.

Real-world examples include the 2020 SolarWinds attack and many recent npm incidents. The Axios attack we’re analyzing today is a textbook (and very sophisticated) supply chain attack.


2. What Is the Axios Package?

Axios is one of the most popular JavaScript HTTP client libraries in the world. It makes it easy to send and receive data over the internet (GET, POST, etc.) in both Node.js (backend) and browser environments.

It has over 100 million weekly downloads on npm and is used by almost every major JavaScript project (React apps, servers, CLI tools, etc.).

Official site: axios.com / GitHub: axios/axios.

Because it’s so widely used, compromising Axios is like poisoning the water supply for the entire JavaScript ecosystem.


3. The Attack (March 30–31, 2026)

On March 30–31, 2026, attackers hijacked the npm account of a lead Axios maintainer (jasonsaayman). They published two poisoned versions:

  • axios@1.14.1 (main branch)
  • axios@0.30.4 (legacy 0.x branch)

These versions were not built through the normal GitHub Actions CI/CD pipeline (which uses secure OIDC tokens). Instead, the attacker manually published them using a stolen long-lived npm access token after changing the maintainer’s email to a ProtonMail address (ifstap@proton.me).

stepsecurity.io

Key trick: The malicious Axios packages themselves contain zero lines of bad code. They simply add one hidden dependency:

  • plain-crypto-js@4.2.1 (published ~18 hours earlier as a decoy).

During a normal npm install or npm update, npm automatically:

  • Downloads the poisoned Axios.
  • Pulls in plain-crypto-js@4.2.1.
  • Runs its postinstall script (node setup.js).

That script is a sophisticated cross-platform RAT dropper (Remote Access Trojan installer). It works on macOS, Windows, and Linux, talks to a live command-and-control server, drops platform-specific malware, and then erases almost all traces of itself.


Key Components of the Attack

ComponentWhat It DoesWhy It’s Sneaky
Compromised Maintainer AccountAttacker changed email & used npm token to publish manuallyBypassed GitHub CI/CD checks
Phantom Dependencyplain-crypto-js@4.2.1 added to package.json but never imported in Axios codeLooks innocent; no code changes in Axios files
Obfuscated setup.jsTwo-layer obfuscation (reversed Base64 + XOR cipher with key “OrDeR_7077”)Static scanners often miss it
Postinstall TriggerRuns automatically when npm finishes installingNo user interaction needed
C2 Serverhttp://sfrclak.com:8000/6202033 (IP: 142.11.206.73)Live server; sends fake “npm-related” traffic
Self-DeletionDeletes setup.js, removes postinstall from package.json, replaces with clean decoy fileAfter infection, node_modules/plain-crypto-js looks 100% legitimate

Platform-specific RAT dropper behavior (simplified)

macOS: Writes AppleScript → downloads binary to /Library/Caches/com.apple.act.mond (mimics Apple system file) → runs in background.

Windows: Copies PowerShell as wt.exe (disguises as Windows Terminal) → runs hidden VBScript + PowerShell script.

Linux: Downloads Python script to /tmp/ld.py → runs detached with nohup.

All versions send a small “beacon” POST to the C2 with a fake npm-looking body (packages.npm.org/product0, etc.) so network logs look normal. The second-stage payloads are full-featured RATs that can run commands, exfiltrate data, etc.

stepsecurity.io


💡
The entire attack happened in under 40 minutes across both Axios branches. It was designed for maximum speed and stealth.

4. How to Detect If You Are Infected

Good news: The malicious packages were quickly detected by Socket Security and StepSecurity within minutes of publication. npm has since removed the bad versions, so new npm install calls are safe now.

Quick Detection Steps (Run These Now)

Check your lockfile (package-lock.json or yarn.lock or pnpm-lock.yaml):

  • Look for axios@1.14.1 or axios@0.30.4.
  • Also look for plain-crypto-js@4.2.1 (or @4.2.0).

Linux investigation commands:

# Search for malicious versions in lockfiles
grep -R "axios@1.14.1" .
grep -R "axios@0.30.4" .
grep -R "plain-crypto-js" .

# Check installed packages
npm ls axios
npm ls plain-crypto-js

# Find suspicious folders in node_modules
find node_modules -type d -name "plain-crypto-js"

# Search for setup.js or postinstall scripts
find node_modules -name "setup.js"
grep -R "postinstall" node_modules/

# Check for suspicious scripts referencing network calls
grep -R "sfrclak" .
grep -R "142.11.206.73" .

Look inside node_modules:

If you see a folder node_modules/plain-crypto-js and it contains setup.js (even if deleted), you were exposed.

After cleanup the folder looks clean, but the presence of the folder itself (when Axios version was 1.14.1/0.30.4) is suspicious.


Indicators of Compromise (IoCs) – Use These to Scan

Malicious Packages (exact shasums):

  • axios@1.14.1 → shasum: 2553649f2322049666871cea80a5d0d6adc700ca
  • axios@0.30.4 → shasum: d6f3f62fd3b9f5432f5782b62d8cfd5247d5ee71
  • plain-crypto-js@4.2.1 → shasum: 07d889e2dadce6f3910dcbc253317d28ca61c766

Network IoCs:

  • Domain: sfrclak.com
  • IP: 142.11.206.73
  • URL: http://sfrclak.com:8000/6202033
  • POST bodies: packages.npm.org/product0 (macOS), /product1 (Windows), /product2 (Linux)

File-system artifacts (if RAT ran):

  • macOS: /Library/Caches/com.apple.act.mond
  • Windows: %PROGRAMDATA%\wt.exe, temporary files in %TEMP%\6202033.*
  • Linux: /tmp/ld.py

Linux forensic commands:

# Check for dropped payloads
ls -la /tmp/ld.py

# Check running suspicious processes
ps aux | grep -E "ld.py|node|wt.exe"

# Check network connections
netstat -antp | grep 142.11.206.73
ss -antp | grep sfrclak

# Check bash history for suspicious execution
grep "ld.py" ~/.bash_history

# Check cron jobs for persistence
crontab -l
ls -la /etc/cron*

Tools to help scan:

  • Use npm audit, Socket Security, or StepSecurity’s tools.
  • Check your CI/CD logs for installs between March 30 23:59 UTC and the time npm removed the packages.

stepsecurity.io


5. If You Are Infected – What to Do Right Now

Immediate isolation:

  • Stop any running Node.js processes that might be the RAT.
  • Disconnect affected machines from the network if possible.

Clean & Reinstall:

rm -rf node_modules package-lock.json
npm install axios@1.14.0   # or latest safe version (check axios.com for current)

(Use ^1.13.x or whatever your project pinned before if you want to be extra safe.)

Forensic cleanup:

  • Delete the suspicious plain-crypto-js folder completely.
  • Scan for the file artifacts listed above and remove them.
  • On macOS/Windows/Linux: Check for the RAT binaries/scripts and delete.

Rotate secrets:

  • Change any API keys, passwords, SSH keys, cloud credentials that the machine had access to.
  • Assume the RAT may have exfiltrated data.

Long-term prevention:

  • Pin exact versions in package.json (avoid ^ ranges for critical deps).
  • Use npm audit + security scanners (Socket, Snyk, etc.) in CI.
  • Enable two-factor auth + short-lived tokens on npm/GitHub.
  • Consider tools that block “brand-new” dependencies (cooldown checks).

The Axios team and npm security responded extremely quickly. This attack was stopped before it could spread too far, but it shows how even the most trusted packages can be weaponized in seconds.

Stay safe, audit your lockfiles today, and keep your dependencies pinned and scanned! If you need help checking a specific project, drop the package-lock.json (redacted) and I can help spot issues.

Read more