A single command, typed thousands of times a minute across the planet, used to hand total strangers permission to run code on your machine without asking first.
That permission existed quietly for sixteen years.
Nobody outside security teams thought much about it.
Then, this past summer, the organization behind the world’s most used code library switched it off, closing a door that had stayed wide open for years.
Millions of developers type that same command every single day.
So what does flipping one switch actually change for all of them?
Why installing code used to mean trusting it blindly
Every time a developer pulled in an open source package, the package manager didn’t just copy files onto the hard drive. It also let that package run its own setup scripts automatically, little programs labeled preinstall, install and postinstall that fired the instant the download finished, no questions asked.
That handoff made sense for legitimate build steps, like compiling a native extension or setting a file permission. But it also meant any attacker who slipped malicious code into those scripts got a guaranteed unsupervised window to run it the moment someone typed install.
So attackers used it constantly, over and over, year after year. Security researchers have called install-time lifecycle scripts one of the most abused entry points into the open source supply chain, a known weak spot that kept getting exploited anyway because changing the default risked breaking countless existing build pipelines overnight.
The moment the default actually flipped
That changed on July 8, when version 12 of the npm package manager shipped as the default release and, as one report put it, turned three previously automatic install behaviors into things developers must now approve.
The headline change is simple. AllowScripts now defaults to off, so lifecycle scripts from any dependency sit inert until a developer deliberately allows them to run.
Npm also stopped automatically pulling code straight from Git repositories and remote tarballs, closing two more paths attackers had used to smuggle in unreviewed code before a developer ever saw a file listing.
One security write-up called it a response to the single largest code-execution surface in the npm ecosystem, since it blocked the vector itself rather than trying to detect bad scripts after the fact. None of this was sudden; GitHub, which maintains npm, had previewed the changes for weeks before the switch flipped, giving large companies time to audit which of their own build steps actually depended on scripts running automatically.
What the hard numbers show about the scale of the problem
The urgency wasn’t theoretical. In the months before npm 12 shipped, researchers tracked real compromises moving through exactly the install script mechanism the update targeted, including a supply chain worm that compromised dozens of packages within hours.
One security vendor framed the payoff in blunt terms.
It argued the change closed off a large share of a common attack path by changing a single default, according to an analysis published ahead of the release.
A widely covered March compromise of the axios library, which carries over 100 million weekly downloads, had already shown how fast a poisoned package could spread through dependent projects before anyone noticed; attackers used a hijacked maintainer account to publish versions that pulled in a malicious dependency during the install step. That pressure made a default this disruptive politically possible to ship. Even so, npm 12 does not fail an install when it skips a script, so teams get a warning instead of a broken build on day one, a softer landing meant to buy time for migration.
Where the fix still falls short
Turning off scripts closed one door, but attackers walked through another almost immediately. In October, researchers disclosed a flaw in npm’s newer trusted publishing system, the mechanism meant to replace risky long-lived passwords with short-lived tokens issued automatically by build pipelines.
The flaw worked because npm checked the repository name and workflow filename without verifying the permanent repository ID. That gap meant an abandoned project name could be reclaimed and used to publish fresh, malicious versions of a package that still trusted it, even though the original repository behind that name no longer existed.
The exposure was not small. The scan found more than 1,500 vulnerable packages with over 10 million combined downloads, echoing the cascading worm behavior covered in earlier reporting on strangers running code on developer machines. GitHub moved fast, and now expires unvalidated publisher bindings after 48 hours, shrinking the window an attacker gets to exploit a reclaimed name.
What comes next for developers and the tools they trust
About two and a half weeks after that patch, GitHub opened a new package firewall in public preview, a proxy sitting between developer machines, build runners and coding agents and the public registry itself, inspecting every request before a package reaches a laptop.
The timing matters because of who does the installing lately.
Security researchers have noted that automated coding agents now install dependencies on their own at meaningful scale, a reminder that much of today’s dependency installing is no longer a human reading a file list, a shift that matters for how tools like automated coding assistants are supervised.
So the firewall adds a minimum package age, letting a fresh release sit before anyone can install it. For now it only covers npm packages, limited to GitHub Enterprise Cloud customers, with wider rollout still pending.
But each layer, scripts off by default, faster token expiry, a screening proxy out front, shrinks the quiet window attackers depend on, one small default at a time.
