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.

ThreatVectr Newsdesk· 3 min read
Full-frame photoreal editorial image of a darkened developer workstation with a large monitor showing abstract cascading package dependency graphs in green and
Share

Key points

  • GitHub released npm version 12 with install scripts disabled by default, a change that stops downloaded packages from automatically running code on a developer's machine.
  • The company is deprecating granular access tokens, or GATs, that 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 now opt in using the new allowScripts flag.
  • The changes were announced by GitHub, which owns npm through its parent Microsoft.

npm is the world's largest software library for JavaScript, the language behind most websites. Developers pull small packages from it billions of times a week.

That scale is also its weakness. When a developer installs a package, npm has long allowed that package to run little setup programs called install scripts. Attackers have used those scripts to quietly execute malicious code on the developer's computer the second the download finished.

GitHub, which runs npm and is owned by Microsoft, has now changed the default. In npm 12, install scripts do not run unless the developer explicitly turns them on with a new flag called allowScripts. In plain terms: a freshly installed package can no longer execute code on your machine without your say-so.

As first reported by The Hacker News, GitHub is pairing that change with the retirement of granular access tokens, known as GATs. These were credentials developers could use to publish packages. The problem was that GATs could be used without two-factor authentication, the extra login step (usually a code from your phone) that stops an attacker from logging in with just 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 end up inside banking apps, hospital software, and government portals within hours.

Over the past two years, criminals have repeatedly slipped malicious code into popular npm packages. Some steal cryptocurrency. Some steal login credentials for cloud services. Some install back doors that let the attacker return later. In several cases, the malicious code was hidden inside an install script and ran the instant 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, for example native database drivers, will need the developer to opt in per install or per project. GitHub's guidance is to opt in narrowly, not globally.

Second, granular access tokens are being wound down in favour of tokens that require two-factor authentication to publish. Publishers who still rely on GATs in automated pipelines will need to migrate before the deprecation window closes. GitHub has said it will publish timelines in its changelog.

There is a trade-off. Some existing build scripts and continuous integration pipelines will break the first time they run against 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 the coming months, the odds that a poisoned package silently infects the software supply chain drop, because the easiest attack path, an auto-running install script, is now closed by default.

It is a sensible correction to a default that should probably never have shipped the other way.

© 2026 Threat Vectr