Home
AI
Blog

Axios Got Hacked: Detect the npm RAT and Fix Fast

basanta sapkota


Ever had a build go green… and still feel your stomach drop? Yeah. That’s the mood with “axios got hacked.” You can be “doing everything right,” run a boring old npm install, and still end up quietly pulling a Remote Access Trojan onto a dev machine or CI runner without changing a single line of Axios code. Brutal. On March 31, 2026, malicious Axios versions axios@1.14.1 and axios@0.30.4 hit npm through a compromised maintainer account. Those releases pulled in a hidden dependency which executed a cross-platform RAT dropper during install. Axios sits at ~83M to 100M+ weekly downloads depending on who you ask, so this spread panic fast. Details and vendor write-ups are in the Sources section from Snyk, StepSecurity, The Hacker News, Aikido, and Tenable. --- ## The big takeaways - The versions. to avoid are axios@1.14.1 and axios@0.30.4. If you’ve got them anywhere, don’t “wait and see.” Downgrade or pin now. - The nasty part wasn’t “Axios code went evil.” The malicious behavior lived in a dependency, plain-crypto-js@4.2.1, kicked off by an npm postinstall script. - The dropper tried to cover its tracks. It self-deleted and “cleaned” its own package metadata, so poking around node_modules might look weirdly normal. Logs are where the truth shows up. - If you installed those versions during the exposure window, treat it like an incident response situation. Quarantine, rotate secrets, and seriously consider rebuilding hosts. - Longer term, this is the reminder nobody wanted. Pin versions, review lockfile diffs like you mean it, restrict install scripts in CI, and run supply-chain scanning. -

What actually happened in the “axios got hacked” incident

When people say “axios got hacked,” they often picture a malicious PR sneaking into the repo. That’s not what happened here. No dramatic code review failure.Yet obvious bad commit. Per StepSecurity and Snyk, attackers took over npm publishing access for a lead maintainer account and pushed two poisoned releases:

  • axios@1.14.1 in the 1.x line
  • axios@0.30.4 in the legacy 0.x line

Both releases added a dependency, plain-crypto-js@4.2.1, which Axios didn’t even import. It was basically “dead code” from Axios’s point of view, there only to run something during installation. ---

Timeline: this moved in hours, not days

The public timelines from StepSecurity / The Hacker News / Snyk line up pretty cleanly. - Mar 30, 2026. plain-crypto-js@4.2.0 published as a “clean” decoy

  • Mar 30, 2026 23.59 UTC. plain-crypto-js@4.2.1 published with the payload
  • Mar 31, 2026 00.21 UTC. axios@1.14.1 published, pulling plain-crypto-js@4.2.1
  • Mar 31, 2026 01.00 UTC. axios@0.30.4 published, same trick
  • ~03:29 UTC: malicious Axios versions removed, per Snyk

So yeah, axios got hacked, and the blast radius mostly came down to who installed during that window. CI systems doing fresh installs? Especially exposed. ---

Why this worked so well: npm postinstall scripts

Here’s the uncomfortable part. The attack didn’t need a zero-day. It leaned on a normal npm feature. Npm runs lifecycle scripts at different stages, including install-time hooks. Great for native builds. Also great for malware authors. The reference here is npm’s own documentation on scripts and lifecycle behavior:
https://docs.npmjs.com/cli/v11/using-npm/scripts/

In this incident, plain-crypto-js@4.2.1 ran a postinstall hook that executed a dropper script named setup.js. StepSecurity and Snyk describe it as double-obfuscated, pulling a second-stage payload from a live C2 server, then trying to erase evidence after it ran. ---

Indicators of compromise

If you’re hunting for concrete “did this touch us?” signals, these are the recurring artifacts reported across Aikido / Snyk / The Hacker News. ### Versions and dependency to look for

  • axios@1.14.1
  • axios@0.30.4
  • plain-crypto-js@4.2.1
    Some guidance says any plain-crypto-js is suspicious right now because of the npm security hold. ### Network / C2
  • sfrclak[.]com:8000
    This C2 shows up in Snyk, StepSecurity, and The Hacker News reporting. ### Disk artifacts, depending on OS
  • macOS. /Library/Caches/com.apple.act.mond
  • Windows: %PROGRAMDATA%\wt.exe
  • Linux: /tmp/ld.py

And here’s the annoying gotcha again. Multiple sources mention the malware self-deletes and swaps its own package manifest, so node_modules/plain-crypto-js might not look obviously cursed after the fact. That’s why install logs, CI logs, and network logs matter so much. ---

How to check if you’re affected

I’m with Aikido on the approach: don’t overcomplicate it. Confirm the versions first, then go looking for artifacts. ### 1) Check for the malicious Axios versions

npm list axios 2>/dev/null | grep -E "1\.14\.1|0\.30\.4"

Also check your lockfile:

grep -A1 '"axios"' package-lock.json | grep -E "1\.14\.1|0\.30\.4"

2) Look for the hidden dependency

ls node_modules/plain-crypto-js 2>/dev/null && echo "POTENTIALLY AFFECTED"

3) Look for OS artifacts

macOS / Linux

ls -la /Library/Caches/com.apple.act.mond 2>/dev/null && echo "COMPROMISED"
ls -la /tmp/ld.py 2>/dev/null && echo "COMPROMISED"

Windows (CMD)

dir "%PROGRAMDATA%\wt.exe" 2>nul && echo COMPROMISED

https://www.basantasapkota026.com.np/2026/03/dynamic-workers-cf-run-untrusted-code.html

Remediation: what I’d do on a real team

Tenable is pretty blunt here, and I agree with the vibe. If those versions landed on a machine, treat it as compromise, not “potential risk.” Don’t just bump Axios and move on like nothing happened. That’s how you get haunted later. ### Immediate actions

  1. Quarantine affected machines or runners

  2. Rotate secrets reachable from host
    Think npm tokens, cloud credentials, SSH keys, .env values, CI secrets. All of it. 3. Downgrade or pin to known-good releases. Aikido recommends:

    npm install axios@1.14.0

# 1.x users
npm install axios@0.30.3

# 0.x users

  3. If you found RAT artifacts like com.apple.act.mond, wt.exe, or ld.py, rebuild from known-good images. Cleaning in place tends to turn into a long, messy time sink and you still won’t be sure you got everything. ### Hardening so the next “axios got hacked” doesn’t torch your on-call week

Pin and lock dependencies. Don’t float on ^ unless you truly mean “surprise me.”
Get serious about lockfile diffs in PRs. Treat them like code, because they are. In CI, consider npm ci --ignore-scripts where it’s feasible. It breaks some builds, sure, but it also shuts down a very common malware route. And add supply-chain scanning. Snyk and others flagged this quickly. Pick a tool you’ll actually run, not the one looks coolest in a slide deck. If you want the deep technical chain, both of these write-ups are solid and detailed. - https://snyk.io/blog/axios-npm-package-compromised-supply-chain-attack-delivers-cross-platform/

Axios got hacked. We can still respond like adults. This was classic supply-chain strategy. Compromise publishing, inject a dependency, run it during install, wipe traces. So the response is two-sided. Incident response now, meaning quarantine, rotate, rebuild if you have to. Engineering hygiene later, meaning pinning, log review, CI restrictions, scanning. If you haven’t already, run the version checks across your repos and your CI logs.Now you did find 1.14.1 or 0.30.4, I’d genuinely like to hear what tipped you off and what you’re changing in your pipeline. 

Sources

Post a Comment