If you use Axios (which, let's face it, is almost everyone in the JS world), you need to check your dependency tree immediately. On March 31, 2026, a maintainer's account was compromised, leading to the release of malicious versions of the popular HTTP client.
Here is a breakdown of what happened, how it works, and how to secure your apps.
The Incident at a Glance 📉
Date: March 31, 2026
The Cause: A compromised npm account of an Axios maintainer.
Affected Versions: 1.14.1 and 0.30.4.
The Payload: A dependency on a malicious package called plain-crypto-js.
Reach: Axios is downloaded ~100 million times per week. Even though the versions were removed within hours, thousands of environments were exposed.
How the Attack Works 🔍
The attacker gained access to the maintainer's account and published the malicious versions directly to the npm registry.
The Dropper: The malicious versions included setup.js, which downloads platform-specific payloads from a remote server (sfrclak.com:8000).
The RAT (Remote Access Trojan): The secondary payloads act as lightweight Trojans that "beacon" back to the attacker every 60 seconds, sending system info and waiting for commands.
Self-Cleaning: To avoid detection, the malware attempts to delete itself and restore a clean package.json after the initial infection.
Multi-Platform: It has custom payloads for:
macOS: A C++ binary capable of self-signing.
Windows: A PowerShell script that hides in the registry.
Linux: A Python script.
Immediate Action Plan ✅
If you find these versions in your environment, follow these steps:
Revert and Audit
Force your version of Axios to a known safe version (e.g., 1.14.0 or 1.15.0 once available). Use npm ls axios to check your entire tree.Rotate Credentials
If the malicious code was executed in your CI/CD pipeline or local machine, assume all environment variables, API keys, and tokens are compromised. Rotate them immediately.Clear Caches
Clear your local and CI caches to ensure the malicious tgz files aren't being reused.Monitor Network Traffic
Check your logs for any outbound connections to sfrclak[.]com or the IP 142.11.206.73.
Preventing Future Attacks 🛡️
Supply chain attacks are becoming more frequent. Here are a few tips to stay safe:
Pin your versions: Avoid using ^ or ~ for critical dependencies in production. Use a lockfile.
Use Socket or Snyk: Tools that analyze the behavior of a package update, not just known vulnerabilities.
Enable 2FA: If you are a maintainer, please ensure 2FA is mandatory for all publishing actions.
Stay safe out there! If you've encountered this in your builds today, let us know in the comments how you handled the cleanup.
Top comments (0)