npm's Frictionless Publish Era Is Over

Between March and July 2026, GitHub quietly rewired how the npm registry and GitHub Actions behave by default, then summed it all up in one consolidated post. The individual items read like routine hardening. Together they're something bigger: the end of the frictionless-publish era that made npm both the world's largest package registry and its most productive malware distribution channel.

The list is long, and almost none of it is opt-in. High-impact npm accounts now go read-only for 72 hours after an email change or a 2FA recovery-code login — the exact sequence the account-takeover playbook has used for years. Staged publishing holds new versions in a queue until a maintainer approves them with a fresh 2FA challenge, which means a stolen CI credential alone can no longer ship code. actions/checkout stopped checking out untrusted fork code on the triggers that power "pwn request" attacks, a fix GitHub backported to older pinned versions. The Actions cache went read-only for untrusted workflows so a low-privilege foothold can't poison the cache a release job reads from. Dependabot now waits three days before opening version-bump PRs (security fixes are exempt). And npm v12, shipped in July, disables install scripts, git dependencies, and remote-URL tarballs unless you explicitly allow them.

That last one is the big swing. For sixteen years, every package on npm carried an implicit right to execute arbitrary code on your machine at install time, and only a tiny fraction ever needed it. The postinstall hook was the propagation engine behind the worst incidents of 2025 — the Shai-Hulud worm that backdoored hundreds of packages, the chalk/debug compromise before it. npm v12 doesn't patch that hole; it removes the feature.

The debate GitHub didn't win

The Hacker News reaction to the consolidated post mostly skipped the individual controls and went straight at the philosophy: why is GitHub building waiting periods instead of merging the package-signing support people have been requesting for over a decade? Linux distributions have signed packages since the nineties. One commenter dismissed the cooldown approach as "the lowest tech solution to a technological problem." Another described buying an expired domain that belonged to an npm package author for eight dollars, inheriting the ability to reset the account and ship code to roughly 70,000 downstream companies — and argued, correctly, that a 72-hour freeze does nothing against an attacker who already controls the recovery path and can simply wait.

Here's the thing, though: the signing crowd is fighting the last war. Author-side signing — maintainer-held keys, Debian-style — protects against a compromised registry. Almost none of the actual npm incidents involved a compromised registry. They involved compromised maintainers: phished credentials, stolen tokens, hijacked CI. A phished maintainer signs the malicious release with their own perfectly valid key. Even the strongest pro-signing argument got undercut in the same thread, when a defender of the Linux model conceded that distros are safe mostly because few people can push and updates take time to land — which is a description of waiting periods and least privilege, not cryptography.

And npm isn't actually signing-free. Since 2023 it has supported Sigstore-backed provenance attestations that cryptographically bind a package to the exact repo and CI run that built it — a scheme PyPI pioneered with trusted publishers and npm adopted after. Trusted publishing, which gained CircleCI support in April alongside GitHub Actions and GitLab, replaces long-lived tokens with short-lived OIDC credentials entirely. Identity-bound provenance plus process gates is a coherent security model. It's just not the one people spent ten years asking for.

Where the critics do land a punch is on the gaps. The 72-hour freeze assumes someone is watching during those 72 hours; attackers ship on Friday nights precisely because maintainers don't. Account-recovery weaknesses like expired domains sit upstream of every control on this list. Delays raise the cost of an attack without changing whether it's possible.

What you actually have to do

If you publish to npm, the migration path is now unambiguous, and half of it already happened to you: classic tokens were revoked outright last December, and write-enabled granular tokens default to seven-day expiry with a 90-day cap. Fighting token rotation is a losing game — move publishing to trusted publishing with provenance, and if your package is high-impact, turn on staged publishing and restrict OIDC to stage-only. That combination means an attacker who fully owns your CI still ends up staring at a 2FA prompt only a human maintainer can pass. It's the single strongest control in the entire batch, and it's the one worth adopting even if nothing forces you to.

If you consume packages, npm v12 will break things, and that's partly the point. Audit which of your dependencies actually need lifecycle scripts — native modules pulling in node-gyp builds are the usual suspects — and allowlist them deliberately instead of flipping the global switch back on. Git and tarball-URL dependencies deserve the same scrutiny; most are lockfile archaeology nobody has questioned in years. And check your Actions workflows: the new checkout defaults and read-only cache can stall pipelines that leaned on fork-triggered writes, and workflow execution policies now let org admins restrict trigger types centrally, so coordinate before your release job dies in the dark.

The real loser here is the fully unattended release pipeline — tag push in, published package out, no human anywhere. That pattern is now structurally penalized, and teams that built elaborate zero-touch automation will resent re-inserting a human approval into it. They should make peace with it. Every serious registry is converging on the same shape: short-lived identity instead of secrets, provenance instead of author signatures, and deliberate friction at the exact moments attackers depend on speed. npm was the loosest major registry for fifteen years and paid for it all through 2025. Defaults are the only security mechanism that reliably reaches all of a registry's users — and GitHub finally started using them.