On October 13, 2025, important security changes to npm authentication took effect: new token lifetime limits (90-day maximum, 7-day default), mandatory granular access tokens replacing legacy classic tokens, and TOTP 2FA restrictions in favor of WebAuthn. Classic tokens will be revoked entirely by mid-November.
The changes align npm with modern security practices followed by AWS, Google Cloud, and GitHub. But there's an uncomfortable question the security community isn't asking loudly enough: would any of this have prevented the attacks we've actually seen?
The answer is no.
The Real Attack Vectors
Let's examine the evidence. Just days before npm's announcement, on September 8, 2025, one of the largest npm supply chain incidents in recent history unfolded when popular libraries like debug and chalk along with 16 other utilities were hijacked and pushed to npm with malicious code targeting cryptocurrency wallets.
How did it happen? The maintainer confirmed that their npm account was phished through a highly convincing 2FA reset email sent from a fake domain (npmjs.help). The attacker didn't need to steal a long-lived token. They didn't exploit weak token permissions. They simply sent a convincing email and collected the username, password, and a live TOTP code, then used these to fully take over the account and publish malicious versions.
The malicious versions were live for only two hours, yet during the short 2-hour timeframe in which the malicious versions were available on npm, the malicious code successfully reached 1 in 10 cloud environments. Token lifetime was irrelevant—the attacker had full account access and could generate new tokens at will.
Earlier in 2024, we witnessed an even more sophisticated attack. The XZ Utils backdoor involved a threat actor who spent approximately two to three years building credibility as a contributor named Jia Tan, slowly gaining maintainer responsibilities through sustained social engineering. Starting in 2022, suspected sock puppet accounts began pressuring the original maintainer about their lack of speed in applying updates, eventually leading to Jia Tan being granted maintainer status.
Once trusted, Jia Tan introduced backdoor code in February and March 2024 that targeted the XZ Utils build process, aiming to push backdoored code to major Linux distributions. This attack earned a CVSS score of 10.0, the highest possible rating, and was only discovered after a Microsoft developer investigated a 500ms latency issue. We got lucky.
Neither attack involved stolen tokens. Neither would have been prevented by shorter token lifetimes.
What npm Is Actually Fixing
To be clear, npm's changes aren't without value. Long-lived tokens are a primary vector for supply chain attacks, and shorter lifetimes limit the window of exposure. The shift from TOTP to WebAuthn-based authentication is genuinely better—passkeys are harder to phish than one-time codes.
But these are hygiene improvements, not fundamental security transformations. They address the scenario where:
- An attacker steals a token from a CI/CD system
- The token has write permissions
- The maintainer doesn't notice for months
- The attacker uses that specific token to publish malicious packages
This is treating the symptom (token exposure) rather than the disease (lack of code review, insufficient provenance, maintainer account security, and fundamentally, the ease with which malicious code can be published).
The Hard Problems npm Isn't Solving
The September 2025 npm attack demonstrates the core vulnerability: A single compromise cascaded across the ecosystem in a matter of hours, showing how even one targeted phishing attack can ripple through the entire open-source supply chain. With 2.6 billion weekly downloads across just 18 packages, the blast radius was enormous.
Yet npm's security overhaul doesn't address:
- Account takeover via phishing: The September attack succeeded despite the maintainer having 2FA enabled. A convincing fake domain (npmjs.help instead of npmjs.com) was enough. Shorter token lifetimes are irrelevant when attackers control the account itself.
- Social engineering attacks: The XZ Utils incident demonstrated that social engineering techniques have much lower technical requirements to gain full access to development environments than prior supply chain attacks. No amount of token rotation prevents a malicious actor from spending years gaining community trust.
- Malicious code detection: A legitimate maintainer with proper credentials can publish anything. The malicious code injected into the compromised npm packages was specifically designed to target cryptocurrency wallets, hooking critical functions to intercept web traffic and wallet interactions in real time. There's no systematic review catching this before publication.
- The maintainer trust problem: Open source runs on trust. Developer Josh Junon, commonly known as 'qix,' had over 1,800 GitHub contributions in the last year—a trusted, verified developer. Yet he received an email to reset his two-factor authentication that looked "very legitimate," but was malicious. How do you protect against this without fundamentally changing who can publish?
What Would Actually Help
The solutions that would materially reduce supply chain risk are expensive, controversial, and fundamentally alter npm's core value proposition of "publish anything, instantly":
- Mandatory code review for high-impact packages: Any package above a threshold of weekly downloads should require review for new versions, especially those adding dependencies or making architectural changes.
- Behavioral analysis at publish time: Automated systems that flag unusual patterns—new dependencies, obfuscated code, network calls to unexpected domains, crypto wallet hooks.
- Maintainer identity verification: Real identity requirements for maintainers of widely-used packages. Not pseudonyms carefully cultivated over years, but verifiable humans.
- Provenance requirements: Mandatory signing and attestation showing not just who published a package, but where the build occurred, from what source commit, and with what dependencies.
- Breakage policies: Major version changes or new dependencies in popular packages should trigger additional scrutiny, not instant publication.
npm's changes will roll out progressively, with token lifetime limits taking effect in early October and classic tokens revoked by mid-November. These changes align npm with industry standards—AWS, Google Cloud, and other platforms moved to short-lived credentials years ago. But alignment with cloud provider security models doesn't solve the unique challenges of open package registries.
The Uncomfortable Truth
npm recognizes that "securing npm is a shared responsibility" and that "these changes may cause temporary friction". But friction is being placed on maintainers—constant token rotation, migration to new authentication methods—while the actual attack surfaces remain largely unaddressed.
The September attack proved it: thousands of developers could have installed malicious packages during the compromise window, and four hours after the compromise was confirmed, npm took down all impacted package versions. The system worked because the community detected the attack quickly and npm could respond. But the community got lucky with a 2-hour window. What about a 2-week window with more subtle malware?
npm has about 2 million packages maintained by thousands of solo developers, many juggling open source as a side project. The platform strongly encourages adoption of trusted publishing (OIDC), which eliminates long-lived tokens entirely by using temporary, job-specific credentials from CI/CD providers. This is good. But even with perfect authentication hygiene, a legitimate maintainer with proper OIDC credentials can still publish a backdoor.
The hard truth is that token rotation and WebAuthn migration are visible security improvements that look good in changelog posts. They address real weaknesses and bring npm into alignment with modern security practices. But they don't solve the fundamental problem: in an ecosystem where anyone can publish anything instantly, the weak link isn't token lifetime—it's trust itself.
Until npm grapples with systematic code review, behavioral detection, and the reality that "publish instantly" conflicts with "publish securely," we're treating symptoms while the disease spreads. The September attack won't be the last. It probably won't even be the worst.