A single typed command has fetched and run code from strangers on developer laptops for more than fifteen years.
Nobody reads it before it runs.
It happens in the blink between hitting enter and seeing the install finish, and that gap has become one of the most exploited doors in software.
The tool behind it is finally shutting that door by default.
How a routine install became a backdoor
Every time a developer runs npm install, the package manager does not just copy files. It also checks whether any of the hundreds or thousands of dependencies in a project define a preinstall or postinstall script, and if they do, it executes that code automatically, with no prompt and no review.
That design dates back to npm’s earliest days, when lifecycle scripts were meant for harmless chores like compiling a native module. Over time it became something else: a way for anyone who slipped malicious code into a popular package to get it running on a victim’s machine the instant they typed one ordinary command.
GitHub, which now runs npm as part of Microsoft, has called install-time lifecycle scripts the largest code execution surface in the entire npm ecosystem. The “npm install” command runs scripts from every transitive dependency, as a result of which a single compromised package anywhere in the dependency tree can run arbitrary code on a developer machine or CI runner. The company said the next major version, npm 12, flips that default so scripts no longer fire unless a developer explicitly allows them first.
The scene that made this urgent
Picture a developer running a routine update on a Monday morning, pulling in the latest version of a dependency used by thousands of other projects. Within seconds, unseen code reaches into system folders, reads saved credentials and quietly phones home to a remote server.
That is not hypothetical. Attackers stole a long-lived npm access token belonging to the lead maintainer of axios, the most popular HTTP client library in JavaScript, and used it to publish two poisoned versions that install a cross-platform remote access trojan this spring, a pattern security teams have now watched repeat across dozens of other packages.
So the fix npm chose targets that exact moment. Under the new rule, a package with an install script simply will not run it, even a script tucked inside a native module build that most developers never knew existed. Developers who need those scripts are not shut out entirely, since they now have to run an explicit approval command that records which packages are trusted, turning a silent default into a conscious choice every time.
What the hardest evidence actually shows
This was not a response to one bad week. Security researchers tracking the npm ecosystem documented large waves of compromised package versions through the spring and summer, many of them using the identical trick of a hidden postinstall hook. In one wave alone, hackers published 639 malicious versions across 323 unique packages in about one hour on May 19 .
GitHub’s announcement of the npm 12 changes came amid a separate campaign Microsoft’s threat intelligence team had just flagged, in which Microsoft Threat Intelligence observed a large-scale npm supply chain attack affecting 140+ packages across the mastra and @mastra scopes on the npm registry , with a postinstall hook used to run a hidden dropper script the moment developers or automated pipelines ran a standard install.
GitHub’s own engineers rolled out the change gradually, first as a warning in an earlier npm release that simply listed which packages would be blocked under the new rule. GitHub recommends that developers prepare for these changes by upgrading to npm 11.16.0 or newer, running the normal install, and reviewing the warnings displayed. That gave teams weeks to audit dependencies before anything broke, a courtesy earlier security pushes rarely offered. A tool this embedded in daily software development workflows cannot flip a switch overnight without breaking builds across companies that never saw the warning coming.
Where the fix runs into real limits
None of this makes the problem disappear. Plenty of legitimate packages genuinely need an install script to compile a native binary for a user’s specific operating system, and those packages will now fail outright unless someone manually approves them first.
That creates friction precisely where developers are least patient, in the middle of installing a dependency they assumed would just work. Maintainers of smaller libraries have already had to add documentation explaining the new approval step, because a confusing missing module error now greets anyone who skips it.
Even so, the rule only protects the install step itself.
Malicious code hidden inside a package’s actual source, rather than its install script, still runs the moment a developer’s program calls that code. Even with install scripts blocked, a compromised package can still execute malicious code at import time, and the real supply chain risk is who controls the package, since one maintainer with publish access and no co-maintainers can push any payload, install script or not. Attackers adapt fast, and campaigns have already begun shifting toward payloads triggered by ordinary function calls rather than install hooks, meaning this fix narrows one door while others stay only partly addressed.
What changes for the average developer going forward
For most people writing code, the practical effect will be small and mostly invisible. A handful of trusted packages will need a one time approval, and everything else should install exactly as it always has.
What changes is the posture underneath that experience. Instead of a system that trusts every dependency’s code by default and hopes nothing malicious slips through, npm now assumes nothing should run without a developer’s knowledge first, a shift that matters for an ecosystem millions of projects, companies and hobbyists depend on without ever thinking about the plumbing.
Security researchers who track this space broadly welcomed the change.
So the next time that familiar install command finishes in a second or two, there is now one fewer silent thing it does along the way. That is a small, unglamorous fix, but for a tool this deeply wired into modern software, unglamorous is exactly what real security progress usually looks like.
