What changed in npm v12
npm v12 shipped on July 8, and it rewrites the default trust model for installing JavaScript dependencies. The headline change is that allowScripts now defaults to off. npm install will no longer run a package's preinstall, install, or postinstall scripts unless the project explicitly allows them. The block extends to implicit native builds, so a package that carries a binding.gyp and triggers an implicit node-gyp rebuild is stopped by the same rule. Two related defaults tighten the perimeter further. Git dependencies require an explicit allow-git flag, and remote URL sources such as https tarballs require an explicit allow-remote flag.
This is the most significant security redesign in npm's sixteen-year history, and it inverts a default that has stood since the beginning. For a decade, installing a package meant granting it arbitrary code execution on the developer's machine and in continuous integration. npm v12 revokes that grant until a team hands it back deliberately. GitHub, which stewards npm, staged the change carefully. Every one of these behaviors has been available behind warnings since npm 11.16.0, which gave teams months to see which of their dependencies would break before the hard default arrived.
Why install-time execution was the problem
The rationale is written in the incident history. Almost every worm and credential stealer that hit the registry since late 2025 ran at install time, exploiting the fact that npm install executed dependency scripts automatically. The Phantom Gyp waves attributed to the Miasma campaign abused exactly the implicit node-gyp path that v12 now closes, compiling malicious payloads during an ordinary install. Because these scripts ran before any application code, they compromised developer workstations and build pipelines at the earliest possible moment, often before a single line of the project's own code executed.
The scale of the underlying problem is hard to overstate. Sonatype's 2026 supply chain report counted roughly 455,000 malicious open-source packages published in 2025 alone, pushing the cumulative total of blocked malicious packages past 1.23 million, a 75 percent jump year over year. Against that backdrop, disabling automatic script execution is the single highest-leverage change npm could make. It removes the default capability that the overwhelming majority of these attacks depended on. The registry is closing the door that attackers walked through most often, and it is doing so at the level where every consumer benefits at once.
How the allowlist works
The migration path centers on an explicit allowlist. Teams run npm approve-scripts to list the packages that carry install scripts, approve the ones they trust, and block the rest with npm deny-scripts. The resulting decisions are written into package.json and committed to the repository, which turns an invisible capability into a reviewed, version-controlled artifact. A security reviewer can now see in a pull request that a new dependency wants to run install scripts, and the team decides consciously whether to grant it. That visibility is a structural improvement over the previous model, where scripts ran silently and unlogged.
npm softened the rollout to avoid breaking the world on upgrade day. By default the behavior is a soft skip, meaning an unapproved script produces a warning while the install still completes. Teams that want stricter enforcement can enable a strict-allow-scripts setting, which is the right posture for continuous integration where an unexpected script should fail the build. This graduated design lets organizations adopt the protection at their own pace, starting with visibility in development and tightening to hard enforcement in the pipelines that build production artifacts.
What will break, and where
The packages most affected are the ones that compile native modules or download binaries during installation. Widely used libraries including sharp, better-sqlite3, bcrypt, and node-sass rely on native builds, and binary downloaders such as Cypress, Playwright, Puppeteer, and Electron fetch platform executables through install scripts. Prisma, which generates a client and pulls engine binaries, sits in the same category. On the first install under v12 without an allowlist, these packages skip their setup steps, and the failure often surfaces later as a missing binary or a broken client rather than an obvious error at install time.
The practical consequence is that teams must inventory their install-script dependencies before upgrading. The good news is that the warnings in npm 11.16.0 and later already surface the full list, so the work can happen ahead of the cutover. We recommend running approve-scripts in a branch, committing the resulting allowlist, and validating a clean install in CI before the team moves to v12. The packages that legitimately need scripts are well known and stable, so the allowlist tends to be short and durable once established. The one-time cost buys a permanent reduction in attack surface.
The token and publishing changes
npm v12 arrives alongside a parallel tightening of publishing security. Beginning in August 2026, granular access tokens that bypass two-factor authentication lose their account and publishing powers, and by January 2027 direct publishing through those tokens is deprecated entirely. The guidance points maintainers toward OIDC trusted publishing, which issues short-lived, workflow-scoped credentials from a continuous integration provider rather than long-lived secrets stored in a pipeline. That model removes the standing token that attackers have repeatedly stolen from misconfigured workflows to push malicious versions of legitimate packages.
Taken together, the install-time and publish-time changes attack the supply chain from both ends. Blocking install scripts protects consumers from malicious code in dependencies they pull, and trusted publishing protects the registry from stolen credentials pushing tainted releases. Enterprises that publish internal packages should start the migration to OIDC now, because the deprecation timeline is firm and retrofitting trusted publishing across many repositories takes planning. The maintainers of widely depended-upon packages face the most urgency, since a compromised publish from a popular library propagates to every downstream consumer within minutes.
What engineering leaders should do
The strategic reading is that JavaScript's package ecosystem is finally moving its defaults toward the principle of least privilege. For years the burden of supply chain safety fell on tooling that teams had to add on top of npm, and the base tool trusted everything. npm v12 shifts that baseline so that the safe behavior is the default and the dangerous capability becomes the exception a team must request. That is the correct direction, and it aligns npm with the broader industry push toward provenance, signing, and scoped credentials that has accelerated across every major registry.
The action for leaders is concrete. Schedule the v12 upgrade deliberately rather than letting it arrive by surprise in a routine dependency bump, audit your install-script dependencies using the warnings already present in recent npm versions, and enable strict enforcement in CI once the allowlist is stable. Begin the move to OIDC trusted publishing for any packages your organization ships. The registry has done the hard part by changing the defaults for everyone. Capturing the benefit requires a modest, planned migration that most teams can complete in a single focused sprint.
