Someone compromised a maintainer account for axios, one of the most widely used JavaScript libraries on the planet. They published malicious versions to npm. And all it took to get infected was running npm install.
Not clicking a dodgy link. Not downloading a suspicious file. Just the normal workflow every developer uses dozens of times a day.
The malicious code executed during installation - before your lockfile even mattered. That's the problem.
What lockfiles actually protect against
Lockfiles - package-lock.json, yarn.lock, pnpm-lock.yaml - solve a specific problem: they ensure that everyone on a team installs the same versions of dependencies. No surprises. No "works on my machine" because someone got a different minor version.
That's valuable. But it doesn't protect you if the version in your lockfile is compromised.
In the axios attack, if your lockfile pointed to one of the malicious versions, you were running malicious code. The lockfile ensured consistency - it didn't ensure safety. It locked in the problem.
Install scripts are the attack vector
Here's what made this attack effective: the malicious code ran in an install script. These are scripts that packages can define to execute automatically when you install them.
Legitimate use cases exist. Compiling native modules. Setting up configuration files. Downloading platform-specific binaries. But install scripts also give packages the ability to run arbitrary code on your machine the moment you add them to your project.
No review step. No warning. You run npm install, and suddenly a package you've never audited is executing shell commands with your user privileges.
That's a big attack surface. And the axios breach showed how easily it can be exploited. Compromise one maintainer account, push a malicious version with an install script, and anyone updating or installing the package automatically runs your code.
How pnpm v10 changes the game
This is where pnpm v10 gets interesting. It introduced a feature that lockfiles can't provide: control over what's allowed to run.
pnpm lets you define a whitelist of packages that are permitted to execute install scripts. Everything else is blocked by default. No exceptions. If a package isn't on your approved list, its install scripts don't run - even if the package is in your lockfile and the version matches.
That's a different kind of protection. Lockfiles control what gets installed. pnpm's safeguards control what's allowed to execute. Both are necessary.
In the axios scenario, if you were using pnpm v10 with install script restrictions enabled, the malicious code wouldn't have run. Even if you installed the compromised version. Even if your lockfile pointed to it. The script would have been blocked.
Supply chain defence in layers
No single tool solves supply chain security. But combining them creates real defence.
Lockfiles prevent unexpected version changes. Install script controls prevent unexpected code execution. Audit tools like npm audit flag known vulnerabilities. Dependency review workflows catch suspicious updates before they merge.
Each layer catches different attacks. Lockfiles won't stop a compromised maintainer. Install script restrictions won't stop a vulnerability in legitimate code. Audits won't catch zero-days. But together, they make attacks significantly harder.
The axios breach was a wake-up call. Not because it was sophisticated - it wasn't. But because it was simple. One compromised account. One malicious publish. And suddenly thousands of projects were at risk.
What developers should do now
If you're using npm or yarn, review your dependencies' install scripts. Most packages don't need them. The ones that do should be scrutinised.
If you're starting a new project or have the flexibility to switch, consider pnpm v10. The install script safeguards aren't perfect, but they close a major vulnerability that other package managers leave wide open.
And regardless of tooling: treat npm install as a potential attack vector. Because it is. Every package you install is code running on your machine. That's not paranoia. That's just how package managers work.
The axios attack succeeded because install scripts are powerful and largely unregulated. Lockfiles couldn't stop it. Audits couldn't stop it. Only runtime restrictions - controlling what's allowed to execute - could have blocked it.
That's the lesson. Lockfiles are necessary. But they're not sufficient. Supply chain defence requires tools that can say no to code that tries to run without permission.