The Axios Supply Chain Attack

Axios became the default HTTP client for many JavaScript teams because it made browser and Node requests consistent. It offered a clean promise-based API, interceptors, timeouts, cancellation, and sane defaults in one small package. Over time, it spread across frontend apps, backend services, CLIs, and CI scripts, which is why an Axios incident has a wide blast radius.

What happened this week was a supply chain compromise, not a normal code bug. For a short window on March 31, 2026, two malicious versions were published on npm: `axios@1.14.1` and `axios@0.30.4`. Axios source files were not visibly backdoored. Instead, published package metadata was changed to include `plain-crypto-js@4.2.1`, a dependency added to run `postinstall`.

So, the attack path was install-time execution. A developer machine or CI runner could pull the compromised version, npm would resolve the injected dependency, `setup.js` would execute, and call out to C2 for a platform-specific second stage. Public analysis shows behavior for macOS, Windows, and Linux, followed by cleanup logic that removed obvious clues. That cleanup step is why some teams initially saw "nothing suspicious" when inspecting package contents after install.

This is what makes the event important beyond Axios. Most engineering teams are still better at reviewing application source than package metadata changes and lifecycle hooks. In this case, the abuse was in dependency injection and `postinstall`, not in request handling code. If your detection model is mostly "scan source and move on," this class of incident can slide through.

If you think your environment may have installed during the exposure window, treat it as potential code execution, not just a dependency rollback. Check lockfiles and CI logs for `axios@1.14.1` and `axios@0.30.4`, look for `plain-crypto-js` in dependency graphs and install artifacts, and review host and network IOCs such as sfrclak.com, 142.11.206.73:8000, /tmp/ld.py, %PROGRAMDATA%\\wt.exe, and /Library/Caches/com.apple.act.mond.

The response pattern is familiar to incident teams: isolate impacted systems, rotate reachable credentials, and rebuild from known-good images. Then close the gap that allowed this path by enforcing lockfiles, preferring deterministic CI installs (`npm ci`), reducing or disabling lifecycle scripts in automation where possible, and monitoring build-runner egress so unusual callback traffic is visible quickly.

Open source is still how most of us ship software. The mindset shift is simple: package installation is an execution boundary now. Teams that treat install-time behavior as a first-class security surface will handle the next incident faster and with less damage.