npm 12 Turns Off Auto-Run Install Scripts to Blunt Supply Chain Attacks
GitHub's package manager for JavaScript now ships with a safer default, and it retires a token type that let developers skip two-factor login.

Key points
- GitHub released npm version 12 with install scripts disabled by default, stopping downloaded packages from automatically running code on a developer's machine.
- Granular access tokens, or GATs, are being deprecated; they previously allowed publishing without two-factor authentication.
- The move follows a run of supply chain attacks in which malicious npm packages ran hidden code the moment they were installed.
- Developers who need the old behaviour must opt in using the new
allowScriptsflag.
Npm is the world's largest JavaScript package library. Developers pull from it billions of times a week, and that scale is its weakness: packages have long been allowed to run small setup programs called install scripts on arrival, and attackers have used that to slip malicious code onto a developer's machine the instant a download finished.
GitHub changed that default in npm 12. Install scripts don't run unless the developer explicitly enables them with a new allowScripts flag. A freshly downloaded package can no longer execute anything on your machine without your consent.
GitHub is pairing that change, as first reported by The Hacker News, with the retirement of granular access tokens. GATs were credentials developers could use to publish packages without two-factor authentication, the extra login step, usually a phone-generated code, that blocks an attacker armed with only a stolen password.
Why does this matter to people who don't write code?
Because almost every website and app you use is built from npm packages, and a single poisoned package can reach banking apps, hospital software and government portals within hours.
Criminals have repeatedly slipped malicious code into popular npm packages over the past two years. Some harvest cryptocurrency wallets. Others steal login credentials for cloud services or install back doors for later access. In one case we covered on 3 July, two look-alike packages copied a legitimate developer tool line-for-line, then quietly opened a back door onto every machine that installed them. The payload in many such attacks lived inside an install script and fired the moment a developer typed the install command.
Turning that behaviour off by default is the kind of unglamorous change that quietly prevents a lot of harm.
What changes for developers
Two defaults are flipping.
First, allowScripts is now off. Packages that genuinely need to compile something at install time, native database drivers being the common example, will need the developer to opt in per install or per project. GitHub's guidance is to opt in narrowly, not globally.
Second, GATs are being wound down in favour of tokens that require two-factor authentication to publish. Publishers relying on GATs in automated pipelines must migrate before the deprecation window closes. GitHub says it will publish timelines in its changelog.
There's a real trade-off here. Some existing build scripts and continuous integration pipelines will break on first contact with npm 12, because they quietly depended on install scripts firing automatically. Teams will need to audit their builds and decide which packages genuinely need scripts enabled.
What ordinary users should do
Nothing on your phone or laptop needs changing. This is a shift inside the developer tooling that builds the software you use.
The practical upside arrives slowly: over coming months, the odds that a poisoned package silently infects the software supply chain drop, because the easiest attack path is now closed by default.
GitHub still has plenty of exposure on other fronts. We've reported separately on attackers mapping companies through GitHub's own public tools and on prompt-injection flaws that let outsiders read private repositories. Fixing the install-script default is overdue and correct; it's not a full stop.



