The Axios RAT — npm supply chain attacks hit a new level of sophistication

Fireship’s March 31 video — “Millions of JS devs just got penetrated by a RAT…” — covers what’s likely the most consequential JavaScript supply chain incident of 2026 so far: a precision-targeted Remote Access Trojan slipped into two axios versions on npm, a library with over 100 million weekly downloads.

The framing matters because this attack wasn’t sloppy. It used legitimate maintainer credentials, suppressed SLSA provenance, switched the publisher email to a Proton Mail address, and waited. By the time anyone noticed, the package was out in the world for hours. The lesson for engineers: the npm supply chain attack pattern has graduated from “spray and pray” to “precision human engineering.”

What actually happened

From StepSecurity’s blog and the r/programming thread (502 upvotes):

• Two versions of axios were published — 1.14.1 and 0.30.4
• No GitHub tag exists for either version. This is a tell — legitimate npm releases match GitHub tags
• SLSA provenance attestations present in 1.14.0 are completely absent in 1.14.1. Another tell
• Publisher email switched from the CI-linked address to a Proton Mail account
• The payload was a Remote Access Trojan — not data exfiltration, not crypto stealing, full remote control

This wasn’t an automated script-kiddie attack. Someone targeted a high-value maintainer, gained access, published two strategically versioned releases (a backport of an older line and a current line — to widen the install surface), and stayed quiet.

The social engineering angle

The r/javascript thread (202 upvotes) surfaces the access vector — one of the affected maintainers describing what happened:

“They scheduled a meeting with me. The meeting was on Teams. The meeting said something on my system was out of date. I installed the missing item as I presumed it was something to do with Teams, and this was the RAT.”

This is the part that should keep working engineers up at night. The attacker didn’t break npm. They didn’t break Teams. They social-engineered a single high-value human. The maintainer had legitimate publishing rights, ran what they thought was a Teams update, and from that point the entire ecosystem was downstream of one compromised laptop.

This is the pattern Fireship correctly emphasizes: the soft target isn’t the registry — it’s the human. A maintainer with access to a 100-million-weekly-download package is a more valuable target than most corporate exec accounts. And the attackers have figured this out.

Creator POV vs Reddit dissent

Fireship’s framing treats this as “another in a series” of npm supply chain attacks — Axios joins a list that already includes the color package compromise and the TanStack mass attack that hit days after Axios. From the creator’s vantage point, this is the new normal — npm is a soft target and engineers need to harden their pipelines.

The Reddit dissent is sharper:

• “Pebkac” — top comment in r/javascript blaming the maintainer for installing an unverified update. This is technically true but ignores that the social engineering was sophisticated, branded, contextually plausible.
• “Why doesn’t npm require packages to be signed?” (178 upvotes in r/programming) — points at the registry’s failure to enforce basic provenance.
• “Why do JS packages need to run scripts after installation?” — the post-install script hook is the actual execution vector that turns a malicious package into RCE. This has been a known foot-gun for years.

The dissent isn’t wrong. The registry could do more. SLSA provenance verification at install time, mandatory signing, post-install script opt-in rather than opt-out — all known mitigations, none widely enforced. The fact that maintainers are still the soft point reflects choices npm and the ecosystem have made.

What working engineers should actually do

Three things this incident reframes:

1. Pin and audit aggressively. Caret ranges in package.json (^1.14.0) automatically pulled in 1.14.1 on the next npm install. Pinning exact versions and using a lockfile that pins the dependency tree prevents auto-upgrades to compromised versions. The downside is dependabot/renovate noise — accept the noise.

2. Adopt a delay-window strategy. pnpm’s minimumReleaseAge setting (a related r/javascript signal) introduces a configurable delay between when a package is published and when your tooling will install it. A 72-hour window catches most of these attacks — by the time the version reaches your CI, the community has flagged it. This is the highest-leverage single defense.

3. Treat npm install as a privileged operation. Post-install scripts run with full user privileges. If you run npm install on your dev machine or in CI with access to production credentials or signing keys, you are one compromised dependency away from full takeover. Move installs to isolated containers, restrict CI secrets, audit what your dev machine has access to.

The honest critique

What this incident does NOT mean:

• It doesn’t mean npm is irreparably broken. The ecosystem still ships. Most packages are fine. The probability of any individual install pulling a compromised version is small.
• It doesn’t mean “stop using JavaScript dependencies.” Every ecosystem has supply chain risk. PyPI, RubyGems, Maven Central — all have had similar incidents. JavaScript’s risk is higher because its dependency trees are deeper, but the pattern is universal.
• It doesn’t mean alternative registries solve this. The attack vector is the human maintainer. No registry change defeats a phished Teams meeting.

But it does mean the bar for “shipping production JavaScript” includes supply chain defense as a first-class concern, not an afterthought. If you don’t have a strategy for what happens when a top-100 npm package gets a malicious version pushed at 3am, you’re flying without a parachute.

For most working engineers in 2026: install lockfile-pinned dependencies, use a release-age delay, isolate your install environments, and assume that “trusted maintainer” is a sometimes-true assumption — not a permanent one.