npm's Biggest Security Overhaul in 16 Years Is Here — Attackers Are Already Adapting

For sixteen years, typing npm install has meant handing every package in your dependency tree — including ones you never chose, buried several levels deep — a blank check to run whatever code it wants on your machine before you’ve so much as opened package.json. npm v12 tears up that blank check. What’s set to ship by the end of July 2026 is being described as the most significant security redesign npm has ever shipped — and the researchers tracking the attacks that forced it are warning, in the same breath, that the people it’s designed to stop are already working out where the new walls don’t reach.

What does npm v12 actually turn off by default?

Three permissive defaults that have existed since npm’s early days go dark. Install scripts — the postinstall hooks that let any package run shell commands the moment it lands on disk — default to off; npm now checks package.json for an explicit allowlist before running a lifecycle script from any dependency, direct or transitive. Git dependencies are blocked by default. And sourcing packages from remote URLs is forbidden unless a developer explicitly opts in.

Tech Times frames the scale of what that closes: for over a decade, running npm install has granted every package in a dependency tree — including packages a developer never directly chose — the implicit right to execute arbitrary code at install time. Only about 2% of npm packages actually need install scripts to function; the rest use them as a convenience shortcut for build steps that could just as easily run explicitly. Under the old architecture, 100% of packages carried that execution right regardless of whether they used it. v12 narrows what Tech Times calls a 98% unnecessary execution surface down to zero, by default.

Why did npm reach for its biggest redesign in 16 years?

Because the last year of attacks kept using the same door. Tech Times ties the v12 overhaul directly to North Korea-linked supply-chain attacks against Axios and Mastra AI, both of which exploited postinstall hooks to get code running on developer and CI machines the moment a package was installed — no application code execution required, just npm install. Cybernews describes the same fix from the defender’s side: installing a package from npm will no longer auto-run code on the system, and npm won’t quietly pull code from an external repository unless a developer explicitly allows it. Two outlets, two ends of the same story — one naming the incidents that forced the change, the other naming the exact behavior it kills.

npm isn’t the only build pipeline that spent 2026 discovering it trusted the wrong step by default — see the AsyncAPI GitHub Actions supply-chain backdoor that hit another widely-used open-source project the same way.

What does the redesign close, and what does it leave open?

Everything at install time. Nothing after the package is already running.

Are attackers already adapting to the new defaults?

Yes, according to Tech Times — by moving the payload from install time to import time. Its reporting points to a case that already shows the workaround in practice: a supply-chain incident where the malicious code did not run during npm install at all. Instead, it activated when a developer or CI job later require()d the package as part of a build or configuration step — import-time execution, not install-time execution, sitting entirely outside what v12’s script-blocking defaults inspect. The expected next move is a heavier concentration of attacks on packages organizations have already approved through allowScripts or similar allowlist configurations, because once a package clears that one-time gate, v12 has nothing left to check.

Isaac Evans, founder and CEO of security firm Semgrep, calls the change “a meaningful step” — while noting, per Tech Times, that it closes only one entry point in a broader attack surface. That’s the crux of the skepticism running through both outlets’ coverage: v12 fixes the specific mechanism the last year’s highest-profile attacks used, without touching the mechanisms researchers expect to matter next.

Does npm v12 actually fix npm’s supply-chain problem?

Not on its own — the account-takeover path is untouched. Cybernews’s coverage is the more skeptical of the two, headlined bluntly: security researchers say the overhaul isn’t enough. Moshe Siman Tov Bustan, a security researcher at OX Security, put the gap in stark terms to Cybernews: “Account takeover remains an open wound. Once an actor controls a legitimate maintainer’s credentials, no amount of install-script blocking helps, because the malicious code ships as a trusted, signed release.” Bustan’s argument goes further: the deepest problem isn’t install time at all. A developer can npm install a package that already contains malicious code or a compromised dependency, and simply running that code — no postinstall script required — is enough to compromise the machine.

Attack vector	Closed by npm v12?	Why
Postinstall/lifecycle script execution	Yes	allowScripts defaults off; explicit package.json allowlist required
Git dependency substitution	Yes	Git dependencies blocked by default
Remote URL package sourcing	Yes	Requires explicit opt-in
Compromised maintainer account	No	Malicious code ships inside a trusted, signed release
Runtime/import-time payload	No	Executes on require(), not on install

What should developer teams do before v12 lands?

Audit CI pipelines now, before the silent exit-code-0 failures do it for you.

That gap — trusted credentials outrunning any perimeter control — isn’t unique to npm. It’s the same failure mode behind Accenture’s own July breach, where leaked keys mattered more than any amount of code review ever could. npm v12 closes the loudest, most automated version of the install-time problem. The quieter version — a real person’s real login, used to ship something the ecosystem already trusts — still isn’t npm’s to fix by default.