How npm Supply Chain Attacks Work: The axios Case Study

Introduction

On March 31, 2026, axios — an HTTP client library with over 100 million weekly downloads — was hit by a supply chain attack. The incident was contained within roughly four hours, but in that short window countless projects around the world were exposed to potential risk.

This is the first article in a three-part series. Using the axios attack as a case study, it analyzes how npm supply chain attacks work. The second article covers the defense strategies applied in a real-world project, with implementation details, and the third examines the effectiveness and limits of those defenses.

What Is a Supply Chain Attack?

A supply chain attack is a method of delivering malicious code to end users through an external component that software depends on — a library, build tool, deployment pipeline, and so on. Rather than attacking the target directly, the attacker first compromises something the target trusts and uses, then travels along that chain of trust.

Common forms include:

• Package registry attacks: Compromising legitimate packages in public registries such as npm, PyPI, or RubyGems
• Build system attacks: Compromising the CI/CD pipeline or build tooling itself (see the SolarWinds and 3CX incidents)
• Maintainer action: A maintainer intentionally inserts malicious code (see colors.js and node-ipc)
• Long-term infiltration: Building a trusted relationship over years before inserting a backdoor (see XZ Utils)

The axios case covered in this article falls under package registry attacks — specifically, a maintainer account hijack.

The axios Attack

Overview

Timeline

The attacker hijacked the account of jasonsaayman, the lead maintainer of axios, and changed the account’s email address to their own ([email protected]). They then bypassed the normal CI/CD pipeline and published the malicious versions directly via the npm CLI — two releases across two release branches (1.x and 0.x) in about 39 minutes.

Legitimate axios releases use GitHub Actions with npm OIDC Trusted Publisher, leaving a cryptographic signature. The malicious versions had no such signature. This became the decisive forensic indicator.

Detection itself was remarkably fast. Socket, a supply-chain security SaaS, flagged anomalous behavior through AI-based package analysis just six minutes after publication. StepSecurity, a GitHub Actions runtime security SaaS, issued an alert shortly after. But during those roughly four hours, installations via auto-update or fresh installs could have already pulled the malicious versions.

Attack Mechanism Analysis

What made this attack sophisticated was not simply modifying one package, but structuring the payload as a two-stage delivery.

Stage 1: Injecting a New Dependency

The attacker first published a new package called [email protected] to the npm registry. Its sole purpose was to run a postinstall script.

The compromised axios version then added this package as a new dependency. On the surface, it looked like an ordinary dependency change in the patch notes — but in practice, every axios installer unknowingly downloaded the malicious payload along with it.

[email protected]
└── [email protected]   ← malicious (exists solely for postinstall)

Stage 2: Executing the postinstall Script

The postinstall hook in plain-crypto-js performed the following:

• Embedded an obfuscated payload decoded at runtime
• Used dynamic module loading to evade static analysis
• Communicated with a C2 server at sfrclak.com (IP: 142.11.206.73)
• Dropped a RAT (Remote Access Trojan) at an OS-specific path

In other words, the moment a developer ran yarn install or npm install — before any application code was executed — their machine or CI server was already backdoored.

Why This Attack Is Dangerous

The Blast Radius Is Enormous

axios is the de facto standard HTTP client across the JavaScript ecosystem — React, Vue, Node.js backends, you name it. Even projects that don’t depend on it directly are overwhelmingly likely to have it come in as a transitive dependency through other libraries.

When a single yarn install pulls in hundreds or thousands of packages, compromising just one of them is enough to put an environment at immediate risk.

postinstall Becomes a Silent Execution Trigger

postinstall is a legitimate npm hook, originally intended for things like compiling native modules. But its ability to execute arbitrary code without the developer’s explicit consent makes it the most attractive entry point for supply chain attacks.

Particularly high-risk environments include:

• Developer machines: High-value assets like browser sessions, SSH keys, and cloud credentials are all present
• CI environments: Deployment tokens and secrets are exposed as environment variables
• Production build servers: A position where malicious code can be injected into build artifacts

Fast Detection Does Not Prevent Exposure

In this incident, Socket AI detected the issue in six minutes and the package was taken down within four hours. That is a very fast response — but in environments where automatic updates run, the install could already be complete within that window.

Auto-update bots like Dependabot or Renovate detect new versions immediately and open PRs. If CI automatically installs dependencies for those PRs — even before a human merges anything — postinstall has already run in the CI environment.

Structural Limits of npm’s Trust Model

The axios attack is not a one-off incident. It is a manifestation of a structural problem. npm’s trust model rests fundamentally on these assumptions:

1. Maintainer accounts are securely managed
2. Maintainers have no malicious intent
3. New versions are published in a verified state

When any one of these assumptions breaks — and there are real-world examples of all three being broken — automatic updates become attack vectors in themselves.

npm trusts maintainers by default, and semver ranges (^, ~) are designed to automatically extend that trust to future versions. That automatic extension is exactly what creates the attack surface.

Key Takeaways

The lessons from the axios attack:

1. “It’s a popular package, so it must be safe” no longer holds

The more downloads a package has, the more attractive a target it becomes. Popularity is a reward for the attacker, not a guarantee of safety.

2. Auto-updates are a double-edged sword

The same mechanism that gets security patches to you quickly is also the fastest way to receive a supply chain attack.

3. postinstall should be treated with suspicion

Scripts that run at install time are essentially RCE (Remote Code Execution). Disabling them by default is the safer stance.

4. Time is the most powerful filter

Malicious packages are almost always caught and removed within hours to days. Not installing a new version the moment it is released is itself a powerful defense. This point is explored with data in Part 3 of the series.

Conclusion

The axios case demonstrates that even a well-maintained, widely trusted package can be completely undefended for four hours. Accepting that fact leads naturally to the next question:

What can we do?

The next article, Supply Chain Defense Strategies and Implementation, covers the three defense strategies applied in a real-world project — GitHub Actions SHA pinning, Dependabot cooldown, and Yarn’s npmMinimalAgeGate — with code-level detail.

Github Sponsor Buy me a coffee

Was my blog helpful? Please leave a comment at the bottom. it will be a great help to me!

App promotion

You can use the applications that are created by this blog writer Deku.
Deku created the applications with Flutter.

If you have interested, please try to download them for free.

word learning app for kids

BlaBoo

Korean TOPIK vocabulary app

TOPIK words

Japanese vocabulary app

Japanese words

Chinese HSK vocabulary app

HSK words