The npm registry just weathered one of its most sophisticated attacks yet. On September 14, 2025, the Shai-Hulud worm infiltrated the JavaScript ecosystem through compromised maintainer accounts, spreading malicious code across popular packages. GitHub’s response signals a significant shift in how we approach security for package registries.

The Shai-Hulud Attack Changed Everything

This wasn’t your typical malware injection. The Shai-Hulud worm was self-replicating, spreading through npm packages while stealing multiple types of secrets—not just npm tokens. It used post-install scripts to propagate, turning trusted packages into attack vectors.

GitHub moved quickly. They removed over 500 compromised packages and blocked uploads containing the malware’s indicators of compromise. However, the damage highlighted a harsh reality: Current authentication methods are insufficient to protect the open-source supply chain.

GitHub’s New Security Roadmap

Starting soon, npm will only support three publishing methods:

Local publishing with mandatory two-factor authentication. No more bypassing 2FA for convenience. If you’re publishing from your machine, you’ll need proper authentication every time.

Granular tokens with seven-day expiration limits. The days of long-lived tokens are ending. These shorter-lived credentials reduce the window for abuse if compromised.

Trusted publishing. This removes API tokens from CI/CD pipelines entirely, letting package repositories verify your identity through your build environment.

What’s Getting Deprecated

GitHub isn’t just adding new security features — they’re removing weak ones:

• Legacy classic tokens are going away
• Time-based one-time passwords (TOTP) are being replaced with FIDO-based 2FA
• Publishing tokens will be disabled by default
• The 2FA bypass option for local publishing is disappearing

These changes might disrupt some workflows. But GitHub plans a gradual rollout with migration guides and support.

Why Trusted Publishing Matters

Trusted publishing started with PyPI in April 2023. The idea is simple: Instead of managing API tokens in your build system, the package registry verifies your identity through your CI/CD platform.

RubyGems added it in December 2023, followed by crates.io and npm in July 2025, and NuGet in September 2025. The timing isn’t coincidental—package registries are racing to eliminate token-based authentication vulnerabilities.

Here’s how it works: When your GitHub Actions workflow runs, it generates a signed token that proves the code came from your repository. The package registry verifies this signature and publishes your package without needing stored credentials.

No tokens to steal. No secrets to manage. No attack surface for malware to exploit.

The Broader Context

The Shai-Hulud attack wasn’t an isolated incident. Package registries have faced a surge in account takeovers recently. Attackers are getting more sophisticated, combining traditional credential theft with self-replicating malware designed specifically for package ecosystems.

The open source community’s response has been swift. The OpenSSF Securing Software Repositories Working Group now recommends trusted publishing as a best practice for security. Package registries are implementing it faster than originally planned.

What Maintainers Should Do Now

Don’t wait for the forced migration. Here’s what you can implement today:

Switch to trusted publishing for all your packages. It’s already available on npm and eliminates the biggest attack vector.

Enable 2FA requirements for all publishing actions on your accounts, organizations and packages.

Use WebAuthn instead of TOTP when setting up two-factor authentication. Hardware keys and biometric authentication are more secure than authenticator apps.

Audit your existing tokens. Review what’s still active and remove anything you don’t actively use.

The Road Ahead

These security improvements come with trade-offs. Some automation workflows will need updates. Some convenience features are disappearing. However, the alternative, watching malware spread through the packages we all depend on, is unacceptable.

The software industry relies heavily on open-source software. When package registries get compromised, it affects everyone downstream. That’s why GitHub’s aggressive timeline makes sense. They’re not waiting for the next attack to implement these changes.

True supply chain security requires the participation of everyone. Package registries can implement better authentication, but maintainers need to adopt these tools to benefit from them. The ecosystem’s security is only as strong as its weakest authentication method.

The Shai-Hulud attack was a wake-up call. Now it’s time to build the defenses that should have been in place years ago.