The npm ecosystem is a core part of modern JavaScript development, but it has long been vulnerable to a quiet and dangerous threat we call supply chain attacks “Shai Hulud attacks” being the primary example of it. Much like the massive sandworms of Arrakis, these attacks operated silently and at scale, automatically stealing and abusing npm classic tokens. The result was compromised accounts, unauthorized package releases, malicious dependency injections, and serious supply-chain damage, often before anyone realized what was happening.

On December 9, 2025, we reached an important turning point. All npm classic tokens were permanently revoked. This was not just another security patch or routine cleanup. It marked a fundamental change in how authentication works with the npm registry.

By moving away from classic tokens entirely, we are closing the door on an entire class of attacks that have plagued the ecosystem for years. While no system can ever be perfectly secure, this change makes large-scale token theft and abuse far harder to pull off, and in many cases, no longer practical at all.

The Anatomy of a Shai Hulud Attack: Why Classic Tokens Were So Dangerous

Before discussing the fix, it helps to understand why npm classic tokens were such an attractive target in the first place. These tokens were long-lived, static credentials that often granted broad publishing permissions. Once created, they could remain valid for months or even years, with no built-in requirement for rotation or reauthentication.

A typical developer workflow looked like this:

A developer runs npm login on their local machine.
A classic token is generated and stored, commonly in the ~/.npmrc file.
That same token is then reused for every publish operation, across projects and environments, often indefinitely.

This persistence is what made Shai Hulud-style attacks possible.

Attackers did not need to break npm itself. They only needed to obtain a token once.

There were several realistic ways this could happen:

• Malicious packages or dependencies
  Compromised packages with install or lifecycle scripts could quietly exfiltrate sensitive configuration or environment data, including authentication tokens, especially in misconfigured or automated environments.
  
• Phishing and social engineering
  Developers could be tricked into revealing tokens through fake npm login pages or convincing security alerts, often without realizing the long-term impact.
  
• Compromised development or CI environments
  Infected machines or exposed CI pipelines frequently stored tokens as environment variables. Once leaked, these tokens could be reused from anywhere, with no expiration and no additional verification.
  

Because classic tokens were reusable, portable, and highly privileged, a single leak was often enough to enable account takeover, unauthorized package publishing, and large-scale supply chain compromise.

Building a Stronger Shield: Session-Based and Granular Tokens

To counter Shai Hulud–style supply chain threats, the npm team introduced a layered defense strategy focused on reducing token exposure and limiting the impact of any single compromise.

Session-Based Authentication for Interactive Logins

The most noticeable change for everyday developers is how authentication works when running npm login.

Instead of issuing long-lived classic tokens, npm now uses temporary session tokens for interactive logins.

When this change first rolled out on December 9, session tokens were limited to two hours. While this significantly improved security, many developers found the short expiration disruptive during normal workflows. Based on this feedback, npm maintainers extended the session duration to 12 hours starting December 12.

Even with this longer window, the security improvements remain substantial.

Shorter lifespan by design
Unlike classic tokens that could remain valid for months or even years, session tokens now expire automatically within hours. This sharply reduces the window of opportunity for attackers if a machine or environment is compromised.

Less exposed by default
Session tokens are not surfaced in token listings or stored in configuration files the same way classic tokens were. This makes them far harder for malicious scripts or compromised dependencies to locate and exfiltrate.

Mandatory 2FA for publishing
When authenticated via a session token, two-factor authentication is enforced for all publishing actions. Even if an attacker manages to obtain a valid session token, they still face an additional and critical barrier before they can publish anything malicious.

Together, these changes fundamentally alter the risk profile of stolen credentials. A captured session token is time-limited, harder to discover, and far less useful on its own. Combined with enforced 2FA, what was once a high-impact breach becomes a much more constrained, detectable, and containable event.

Granular Access Tokens for CI/CD and Automated Workflows

Interactive sessions are not suitable for automation, so CI/CD pipelines and other non-interactive systems still require long-lived credentials. What has changed is how much power those credentials have and how safely they can be managed.

npm now supports granular access tokens that are designed specifically for automated workflows. Unlike classic tokens, these can be tightly scoped, given limited permissions, and configured with expiration dates to reduce long-term risk.

At present, true granular access tokens must be created through the npm website, where you can define their scope, permissions, and lifetime. This ensures automation tokens follow the principle of least privilege from the moment they are issued.

Once created, the npm CLI can be used to list and revoke tokens, allowing teams to quickly respond if a CI environment, repository, or secret store is compromised. The step-by-step procedure for creating, managing, and revoking these tokens is documented in npm’s official documentation, which should be referenced for the most up-to-date guidance.

Key benefits of granular tokens:

• Least Privilege: You can assign specific read, write, or publish scopes to tokens, ensuring they only have the permissions they absolutely need.
• Expiration Dates: Tokens can be configured to expire after a set period (e.g., 30 days, 90 days), forcing regular rotation and limiting exposure.
• Optional 2FA Bypass: For automated workflows where 2FA interaction is impossible, you can explicitly bypass 2FA when creating these tokens (use with extreme caution and only for specific, trusted CI/CD environments).
• Auditable: The ability to list and revoke tokens directly from the CLI improves visibility and management.

What You Need To Do: Adapting to the New Paradigm

If you were still relying on npm classic tokens, your tokens have been permanently revoked by now. Here’s how to adapt under the updated npm security model:

For Local Development:
Run npm login in your terminal. During authentication, you will be prompted for credentials and, where required, two-factor authentication. This process creates a temporary session token that enforces 2FA when publishing.

For CI/CD Workflows:
Generate a new granular access token for your automation workflows. At present, true granular access tokens are created on the npm website, and once created, can be managed (listed and revoked) via the npm CLI. The official npm docs explain this procedure in detail.

Conclusion: Toward a More Secure JavaScript Future

The deprecation of npm classic tokens, along with the move to session-based authentication and granular access tokens, marks a major step forward in npm’s security model. These changes directly address long-standing weaknesses and make large-scale token abuse far harder to pull off.

By adopting these new mechanisms, developers are not just protecting their own accounts and packages. They are helping strengthen the entire JavaScript ecosystem and the software supply chain that depends on it. Attacks like Shai Hulud thrive on long-lived, overly powerful credentials, and npm’s new approach removes much of the ground they once relied on.

Adapting to these changes may require small adjustments in daily workflows, but the payoff is significant. A more secure registry benefits everyone, and collective adoption is what ultimately turns these safeguards into lasting protection for the ecosystem as a whole.