Axios Got Hacked — What Happens When a 40-Million-Download NPM Package Goes Rogue

Last week, the JavaScript ecosystem got another harsh reminder of its most uncomfortable vulnerability. Axios — the HTTP client with over 40 million weekly downloads on NPM — was compromised in a supply chain attack. Security researcher John Hammond’s breakdown of the incident cleared 70,000 views in four days. The developer community is, once again, on edge.

One npm install Away From a Backdoor

The mechanics of a supply chain attack are deceptively simple. Instead of attacking your code, attackers poison the packages your code depends on. When the target is something as ubiquitous as axios, the blast radius is enormous. A single npm install pulls the compromised code into your project, and from there it rides your CI/CD pipeline straight to production.

In this case, the payload was a remote access trojan (RAT) — malware that gives attackers full remote control of the infected system. This isn’t data exfiltration. It’s total server takeover.

Why Axios Makes This Worse

Axios isn’t just popular. It’s infrastructure. Node.js backends, React frontends, Vue apps — if it makes HTTP requests in JavaScript, there’s a good chance axios is involved. Over 100,000 repositories on GitHub list it as a direct dependency. Factor in transitive dependencies and the real number is far larger.

Here’s the kicker: most projects specify axios with a caret range (^) in their package.json. That means every npm install automatically pulls the latest minor or patch version. If a poisoned release lands on the registry, your next build picks it up without anyone making a conscious decision to upgrade.

A Pattern That Keeps Repeating

If this feels familiar, it should. The NPM supply chain has been breached before, and the playbook barely changes.

• ua-parser-js in 2021. Maintainer account compromised, cryptominers injected.
• colors.js and faker.js in 2022. A frustrated maintainer deliberately sabotaged his own packages.
• xz-utils in 2024. A patient attacker spent years earning commit access before planting a backdoor.

The formula is consistent: compromise a maintainer account (or become one), target a package with millions of downloads, and exploit the gap between publication and detection. That gap — hours to days — is where the damage happens.

And the structural weakness hasn’t changed. Publishing to NPM still often comes down to a single account protected by a single auth token.

What You Should Check Right Now

Lock your dependencies. If you’re committing package-lock.json or yarn.lock and using npm ci in your CI pipeline, you’re protected against silent version drift. If you’re not doing this, stop reading and go fix it.

Automate dependency auditing. npm audit is the bare minimum. Tools like Socket.dev and Snyk go further — they monitor behavioral changes in packages. A dependency that suddenly starts making network calls or accessing the filesystem in new ways triggers an alert before it triggers an incident.

Enable 2FA on your NPM account. This is table stakes. If you maintain open-source packages, it’s non-negotiable. If you run a team, enforce it org-wide.

The Uncomfortable Math of Open Source

At the root of all this is a structural problem the industry keeps acknowledging and keeps failing to fix. Billions of dollars of software infrastructure depend on a handful of unpaid maintainers. Axios has a tiny core team. One compromised account puts millions of projects at risk.

Companies consume open source freely but invest in its security grudgingly. Initiatives like the OpenSSF and GitHub Sponsors exist, but they’re a rounding error compared to the scale of the problem. We’ve built a global software supply chain on the assumption that volunteers will keep it secure in their spare time.

The axios incident ultimately comes down to one question: do you actually trust every package in your dependency tree? Think about the last time you looked inside your node_modules folder. If you can’t remember, that’s the problem.