What the Axios Supply Chain Attack Revealed About Lockfiles and pnpm 10

In late March 2026, one of the most widely used JavaScript libraries in the world, Axios, was at the center of a serious supply chain attack.

Let’s break down what happened, why it matters, and what you can do to better protect your applications.

Summary of the attack

On March 31, 2026, attackers compromised an Axios maintainer’s npm account and published two malicious versions:

• axios@1.14.1
• axios@0.30.4

These versions looked legitimate but included a hidden dependency (plain-crypto-js) that executed a malicious script during install.

When a developer or CI system ran npm install axios@1.14.1, npm resolved the dependency tree, pulled in the malicious package, and automatically executed its postinstall script.

This script downloaded a cross-platform (macOS, Linux, and Windows) Remote Access Trojan (RAT), giving attackers remote access to the machine, the ability to execute commands, and access to sensitive data. It also cleaned up traces afterward to avoid detection.

First line of defense: Your Lockfile

Your lockfile (package-lock.json, pnpm-lock.yaml, yarn.lock) is your first real line of defense against supply chain attacks. It doesn’t make your dependencies safe, it makes them predictable.

Without it:

• Every install asks the registry: “what’s the latest allowed version right now?”

With it:

• Every install says: “give me exactly what we already trusted before”

Why this matters

Version ranges like:

"axios": "^1.14.0"

don’t point to a single version, they define a range of possible versions.

So every time dependencies are resolved, you’re effectively trusting future publishes you haven’t seen yet. That’s the real risk: not just what you depend on today, but what could be published tomorrow.

A lockfile removes that uncertainty by freezing the exact version and dependency graph at a point in time. Instead of pulling in whatever is new, your installs remain consistent and repeatable. New releases don’t affect you unless you choose to update.

The limits of a lockfile

A lockfile is not permanent protection. It only works as long as you don’t trigger a re-resolution, and that happens more often than most teams realize. Some actions will always refresh your dependency tree:

• Deleting or regenerating the lockfile
• Running update commands
• Pulling in a new lockfile from a teammate, bot, or CI

Other changes can trigger it indirectly:

• Adding or updating a dependency
• Installing a package that depends on Axios
• Fixing an out-of-sync lockfile

The key point is this: You don’t have to update Axios for its version to change.

Your dependency tree is not a flat list, it’s a graph and changes in one part of the tree can propagate and affect other parts, even when you haven’t touched them directly.

Second line of defense: pnpm 10 safeguards

A lockfile controls what gets installed. But incidents like the Axios attack show that’s only half the problem.

You also need to control what runs during installation. This is where pnpm comes in.

pnpm is a JavaScript package manager known for its performance and efficient use of disk space. In recent versions, especially v10, it has also introduced safeguards that directly address supply chain risk by limiting what dependencies are allowed to do at install time.

pnpm has been actively investing in this area. You can explore the full details on the official documentation.

Delay exposure to new releases

One of the simplest ways to reduce risk is to avoid installing packages the moment they’re published.

# pnpm-workspace.yaml
minimumReleaseAge: 1440 # 24 hours

This introduces a delay before newly published versions are considered installable. In practice, it helps avoid short-lived malicious releases that are quickly discovered and removed.

Control install-time execution

Dependencies are not just code you install, they can execute code during installation through scripts like postinstall. That’s exactly what the Axios attack exploited. pnpm v10 changes the default behavior so that dependencies do not run install scripts unless explicitly allowed.

This removes an entire class of attacks where malicious code executes during install. If certain packages legitimately require build scripts, you can explicitly allow them:

allowBuilds:
  - esbuild
  - sharp

This shifts execution from implicit trust to explicit approval.

Conclusion

• Lockfiles help you to control what gets installed
• pnpm safeguards help control what is allowed to run

Together, they reduce both exposure and execution risk.