npm Security Just Got Stricter, But Attackers Adapt Faster

The headline is that GitHub finally locked down npm security in 2026. The real story is how little that lockdown has actually slowed attackers down: the same week a major install-script protection shipped, a separate campaign had already found a way around it. That gap between "fixed" and "safe" is the part most coverage of npm's security overhaul skips.

Key takeaways

GitHub killed npm's old classic tokens on November 19, 2025 and now caps granular write tokens at 90 days, after more than 500 packages were compromised in a September 2025 phishing and malware wave, according to The Register.
npm 12, released in July 2026, stopped running preinstall, install and postinstall scripts automatically, closing the single most common way malware executed on a developer's machine, per The Hacker News.
Within weeks, a campaign tracked as WEL1DROPPER published close to 800 (later 1,033) malicious packages that skipped lifecycle scripts entirely and told developers to load the malware with a plain require() call instead.
GitHub's next phase, targeted for January 2027, will strip bypass-2FA tokens of the ability to publish packages directly at all.

GitHub Spent a Year Closing npm's Easiest Doors

npm security did not improve through one announcement. It happened in a sequence of specific, dated changes that together re-architected how code reaches the registry. On November 5, 2025, GitHub stopped letting developers create new npm classic tokens, the old, long-lived credentials that had no built-in expiration, according to GitHub's own changelog. Existing classic tokens kept working for two more weeks, then were permanently revoked on November 19, 2025 and replaced with short-lived, two-hour session tokens for anyone publishing from their own machine.

The newer granular tokens got tightened too. Any token with publish permission now requires two-factor authentication by default, and GitHub capped every granular write token at a 90-day maximum lifetime; tokens that were set to outlast that window had their expiration force-adjusted to February 3, 2026. A "bypass 2FA" option still exists for automated CI pipelines, but it is off unless a maintainer turns it on, and GitHub has been steadily narrowing what that bypass can actually do.

The Attacks That Forced GitHub's Hand

None of this happened in a vacuum. In September 2025, phishing emails targeting npm package maintainers combined with secret-stealing malware to compromise maintainer accounts across the registry, and GitHub ultimately pulled more than 500 affected packages, The Register reported. Xavier Rene-Corail, who leads GitHub's security lab, put the urgency plainly: "attackers are not waiting." That line is doing real work here, because it frames the entire rollout that followed as a catch-up operation rather than a planned upgrade.

That framing matters for anyone who manages a Node.js or JavaScript codebase: the registry you depend on every day was being actively exploited while you were running npm install without a second thought.

Close up of hands typing on a laptop keyboard

Install Scripts Were the Oldest Trick in the Book, Until July 2026

For sixteen years, running npm install meant any dependency, no matter how deep in the tree, could silently execute its own preinstall, install or postinstall script the moment it landed on your machine. That was the single most reliable way malware got code execution without a victim ever opening the package or running it directly. npm 12, released in July 2026, finally turned that behavior off by default, The Hacker News reported. Developers now have to explicitly allow-list scripts with npm approve-scripts, and the same release requires explicit approval for git dependencies and remote tarball URLs rather than letting them resolve silently.

It is a genuinely significant fix, and arguably the single most important npm security change of 2026. It is also, by itself, proof that the registry's trust model had been broken for a decade and a half before anyone closed it.

Macro shot of a computer circuit board with components

Attackers Found the Next Door in About Three Weeks

This is the part that should temper any relief about npm 12. Between August 3 and August 5, 2026, barely a month after lifecycle scripts were locked down, a campaign researchers call WEL1DROPPER (tracked separately by Sonatype as "Flooding Dropper") published close to 800 malicious packages to npm, a figure that grew to 1,033 confirmed packages as researchers kept counting, according to The Hacker News and a corroborating research note from the Cloud Security Alliance's threat labs.

✦ Free Newsletter ✦

Never miss a story

Tools, tutorials and AI deep-dives - straight to your inbox, every week.

The packages used plausible, AI-generated names rather than classic typosquatting, a pattern researchers have started calling "slopsquatting." More importantly for the security story, they did not rely on preinstall or postinstall hooks at all. Instead, each package's README simply instructed developers to load it manually with a bare require() call, a built-in Node.js function that npm 12's new lifecycle-script restrictions have no power over. Once loaded, the package fetched an operating-system-specific second-stage payload that delivered a remote access trojan and infostealer on Windows, macOS and Linux, including code that patched Windows' Event Tracing and Antimalware Scan Interface to blind local monitoring tools.

That sequence is the real lesson of 2026: GitHub closed the install-script door, and attackers simply walked through the one standing open next to it, which was always going to be there because require() is how JavaScript is supposed to work.

A padlock resting on a computer keyboard symbolizing security

Who Actually Needs to Act on This

Not every npm user carries the same risk, and treating this as a universal emergency would be its own kind of overreaction.

Act now if: you or your CI pipeline publish packages to npm, especially with automation. Move off any remaining classic or long-lived token immediately, since those are the exact credential type GitHub has spent a year eliminating, and set up trusted publishing (OIDC) or staged publishing with a manual 2FA approval step rather than waiting for the January 2027 deadline to force your hand.
Act soon if: you run `npm install` as part of an automated build without pinned lockfiles or any dependency scanning. The WEL1DROPPER campaign shows attackers now assume install-script protections exist and have already adapted around them, so a lockfile alone will not catch a package you add that has a malicious require() payload.
You can mostly skip the urgency if: you only consume a small, stable set of well-known dependencies, already use lockfiles with hash verification, and do not auto-publish packages from CI. You still benefit indirectly from GitHub's changes, but you are not the primary target of either the token attacks or the WEL1DROPPER campaign.

The Counterargument: Friction Isn't the Same as Failure

The strongest pushback on this piece is that measuring npm's 2026 security push against whether it stopped every attack sets an impossible bar. No credential policy or install-script restriction was ever going to make a 2-million-package registry attack-proof, and PostCSS maintainer Andrey Sitnik has made a sharper point than that: he has warned that trusted publishing can itself "increase risks," because malware that already has a foothold inside a project's CI pipeline can use that same trusted, no-token access to push a legitimate-looking release. Security architecture that trades one kind of exposure for another is not obviously progress.

Lines of code displayed on a monitor in a dark room

That critique is fair, and it is why GitHub's own January 2027 phase targets exactly that gap by requiring a human 2FA approval before a staged release actually goes public, rather than trusting CI access alone. But it does not change the pattern this article is actually about: every fix so far has addressed the specific technique of the last attack, and WEL1DROPPER shipped within a month of the fix meant to stop its predecessor's method. Friction raises the cost of an attack; it has not yet closed the gap between what GitHub ships and what the next campaign already anticipates.

What to Watch Before January 2027

If you maintain or publish anything on npm, the practical checklist is short: kill any classic tokens you still have lying around (they should already be dead, but check), turn on trusted publishing or staged 2FA approval before GitHub forces the migration in January 2027, and stop assuming a clean npm install with no lifecycle-script warnings means a package is safe, since WEL1DROPPER proved that assumption wrong in a matter of weeks. The broader lesson for anyone choosing between pnpm, npm or Yarn is that the registry layer underneath all three carries the same risk, so a different client does not buy you out of this problem. The honest summary of 2026 is not that npm got safe. It is that npm got harder to attack in the three ways people had already been attacking it, and the open question heading into 2027 is simply which door opens next.