GitHub has decided to pull the plug on a long-criticized behavior in npm. Starting with version 12, expected in July 2026, the install command will no longer run preinstall, install, or postinstall scripts from dependencies by default. The change directly targets a vector attackers have exploited with growing success in recent supply-chain incidents.
Developers have known the risks for years. A single compromised package could execute arbitrary code the moment it landed in a project. No user interaction required. Just npm install. And run.
The Register first reported the move. Its coverage highlighted how the feature had become a favored entry point for malicious packages. Now the GitHub Blog has published the official details. In a June 9 changelog entry titled “Upcoming breaking changes for npm v12,” the company laid out the new security posture. The post explains that allowScripts will default to off.
But. This isn’t a total shutdown. Teams can still approve specific packages. The new workflow relies on commands like npm approve-scripts and npm deny-scripts. These tools generate an allowlist stored in package.json. Developers commit that list. Installs stay predictable. Or so the theory goes.
The timing feels deliberate. Just days earlier, security researchers uncovered a wave of attacks that leaned heavily on automatic script execution. On June 1, multiple packages under the @redhat-cloud-services scope were found compromised. Each carried a preinstall hook that fired a massive, obfuscated JavaScript payload. The code, sometimes exceeding 4 megabytes, harvested credentials from cloud providers, CI systems, and registries.
Step Security detailed the breach. Its analysis showed the malware executed before any application code ran. The payload used layered obfuscation. One variant even downloaded Bun to slip past Node-focused detection tools. Similar findings came from Panther and Phoenix Security, which linked the activity to a “Mini Shai-Hulud” worm. That strain builds on earlier toolkits, self-propagating once it steals tokens.
These incidents exposed the fragility. A compromised transitive dependency, one that never even runs at runtime, could still own the build environment. Frontend libraries bundled for the browser suddenly posed backend risks. The blast radius grew fast. Weekly downloads across affected packages reached six figures.
Leo Balter, a maintainer involved in the npm changes, pointed to the Shai-Hulud worm in community discussions. The worm didn’t need exotic tricks. It used the defaults. npm install meant code execution. Version 12 aims to raise the bar.
GitHub’s announcement also tightens other vectors. The –allow-git and allow-remote flags now default to off. This closes paths where a Git dependency’s .npmrc could override the Git executable even when scripts were supposedly ignored. That adjustment was previewed earlier in February. It lands fully now.
Native modules face impact too. Packages relying on node-gyp for compilation will require explicit approval. Think Playwright, Puppeteer, Electron. Anything that compiles or fetches during install. CI pipelines could break without preparation. Warnings already appear in npm 11.16 and later for teams that test the new behavior.
So how do organizations adapt? The GitHub guidance is clear. Run npm approve-scripts –allow-scripts-pending in existing projects. Review the list. Approve trusted packages. Deny the rest. Commit the resulting configuration. Repeat across repositories. Tedious work. But necessary.
Security teams see upside. The change reduces the reproduction factor for supply-chain worms. Fewer packages can silently compromise a machine. That means fewer maintainers become targets. The infection chain slows. Yet risks remain. Code that actually executes at runtime, especially in Node-based CLIs or server-side rendering, can still cause damage. Future Node.js permission model improvements may tighten that further.
Community reaction split. Some developers welcomed the default. “Asking first should have been the default,” one observer posted on X. Others worried about friction. Build tools, monorepos, and legacy dependencies will need updates. Teams that pinned exact versions or used lockfiles gain some protection. But the broader ecosystem must shift.
Microsoft researchers noted parallel dependency-confusion campaigns around the same period. Attackers published packages with inflated versions and obfuscated postinstall scripts. The payloads focused on reconnaissance but could flip to credential theft. Registry operators removed the malicious uploads. Defenders were told to rotate keys, enable two-factor authentication, and audit lockfiles.
The npm v12 update doesn’t solve every problem. It addresses one critical one. Automatic code execution during install has haunted the JavaScript community since its early days. Convenience won out over caution for too long. GitHub, which owns both the registry and the dominant development platform, has now tipped the scales toward safety.
Teams should begin testing today. Install npm 11.16 or newer. Enable the pending script approvals. Observe what breaks in continuous integration. Update documentation. Train developers on the new flow. Those who wait until the July release risk sudden pipeline failures.
The decision reflects a broader industry trend. Supply-chain attacks have escalated. State actors and criminals alike target open-source dependencies. Each successful breach erodes trust. By changing the default, GitHub forces a conversation that was overdue. Explicit permission for execution beats silent compromise. The cost is some added workflow steps. The benefit is a harder target for attackers.
Watch for follow-up guidance. npm may add more granular controls. Package authors could provide signed manifests of expected behavior. Registries might surface script analysis in search results. For now, the immediate action is preparation. Review dependencies. Approve what belongs. Block the unknown. The era of blind npm install ends here.
WebProNews is an iEntry Publication