Axios Got Backdoored: What Developers Need to Know About the npm Supply Chain Attack
The popular HTTP client library Axios was compromised with a malicious dependency, affecting versions 1.14.1 and 0.30.4. Here's what happened and how to protect yourself.
Tob
Backend Developer
If you use Axios in your projects, you need to check your package.json right now. The popular JavaScript HTTP client was hit with a supply chain attack on March 31, 2026.
TL;DR: Axios versions 1.14.1 and 0.30.4 shipped with a malicious dependency called plain-crypto-js@4.2.1 that deployed a remote access trojan (RAT). The attack likely came from a leaked npm token. If you're on either of these versions, treat your environment as compromised and rotate your credentials immediately.
The Attack: What We Know
Axios pulls in over 100 million downloads per week. It's everywhere -- React apps, Node backends, enterprise stacks. When something this big gets backdoored, the entire JavaScript ecosystem feels it.
The malicious package was published as plain-crypto-js@4.2.1 just minutes before the compromised Axios versions shipped. Socket.dev, which caught the attack, confirmed the package delivers a multi-stage payload. It can execute arbitrary commands on your machine, steal system data, and persist across reboots.
Here's the smoking gun: the affected Axios versions do not have corresponding tags on GitHub. Axios maintainers normally publish releases alongside git tags. There is no v1.14.1 tag on the repository. Someone published these versions directly to npm, bypassing the normal release process entirely.
Simon Willison flagged this pattern as a useful heuristic. Last week, a similar attack hit LiteLLM using the same tactic -- packages published to npm without a GitHub release. If a new version of a popular package shows up on npm but has no corresponding git tag or release notes, treat it as suspicious.
How the Attackers Got In
The leading theory is a leaked npm token. Attackers used a long-lived automation token to publish the malicious versions directly to the registry. This is exactly the scenario that trusted publishing is designed to prevent.
Trusted publishing ties npm releases to GitHub Actions workflows. Only code that actually runs through your CI pipeline can be published. No token needed on the developer's machine, no token that can be leaked.
The Axios team has an open issue to adopt trusted publishing. If you're a maintainer of a popular npm package and haven't enabled it yet, this should be your top priority.
What You Should Do Right Now
First, check what version of Axios you're running.
npm list axiosIf you're on 1.14.1 or 0.30.4, do the following immediately:
- Pin to a safe version. Axios 1.14.0 appears clean. For the 0.x branch, anything before 0.30.4 is safe.
- Audit your environment. Assume credentials were stolen. Rotate any secrets that lived in the same environment as your Axios installation -- API keys, cloud credentials, database passwords.
- Revoke and re-issue tokens. Any long-lived npm tokens on your machine or in your CI should be regenerated.
- EnableSigstore for your packages. If you're a maintainer, look into Sigstore's keyless signing. It ties releases to real GitHub Actions runs without the token management headache.
The Bigger Picture
Supply chain attacks on JavaScript packages are not slowing down. Axios is the fourth major target in recent months. The economics are brutal -- compromise one package and you get access to every application that depends on it.
For developers, the practical takeaway is to audit your dependency trees regularly and watch for versions that ship without corresponding releases on GitHub. Tools like Socket.dev, Dependabot, and npm audit can catch suspicious behavior, but only if you actually read their output.
For maintainers, the message is clear: adopt trusted publishing. Your users are trusting your package to not steal their data. That trust extends to your release pipeline.
Sources: Socket.dev research, Simon Willison's blog, Hacker News
