npm's Authentication Overhaul: Progress Made, Risks Remain

npm recently completed a major authentication overhaul in December 2025, eliminating classic tokens and enforcing multi-factor authentication (MFA) to address supply-chain vulnerabilities. While these changes represent meaningful progress, the platform remains susceptible to certain attack vectors that developers need to understand.

The Original Problem: Classic Tokens

Historically, npm relied on long-lived, broadly scoped credentials that could persist indefinitely. If stolen, attackers could directly publish malicious versions to an author's packages without needing publicly verifiable source code. This made npm a prime vector for supply-chain attacks, as demonstrated by incidents like Shai-Hulud, Sha1-Hulud, and attacks on popular packages like chalk and debug.

npm's Solution: Session Tokens and MFA

The npm team implemented several key changes:

• Revoked all classic tokens and defaulted to session-based tokens instead
• Short-lived session tokens (typically two hours) obtained via npm login
• MFA enforcement for publishing operations
• OIDC Trusted Publishing encouragement for CI systems to obtain short-lived, per-run credentials

These practices improve security by ensuring credentials expire quickly and requiring a second factor during sensitive operations.

Remaining Vulnerabilities

Despite these improvements, two critical issues persist:

1. MFA Phishing Still Works

The original attack on tools like ChalkJS succeeded through MFA phishing on npm's console. Attackers tricked maintainers into sharing both their login credentials and one-time passwords. Future similar campaigns could obtain short-lived tokens, which still provide enough time to upload malware since that process only takes minutes.

2. Optional MFA Bypass

Developers can still create 90-day tokens with MFA bypass enabled in the console. These tokens are extremely similar to the classic tokens from before, allowing read/write access to a token author's maintained packages. If bad actors gain console access with these settings, they can publish new malicious packages on the author's behalf.

Recommendations for Improvement

In the spirit of open source security, several recommendations could further harden npm's security posture:

• Enforce OIDC adoption in the long term, as it's very hard to compromise and would almost completely eliminate supply-chain attack issues
• Require MFA for local package uploads via email code or one-time password to reduce the blast radius of worms like Shai-Hulud
• Add metadata to package releases so developers can avoid packages or maintainers who don't take supply chain security measures

A Different Approach: Building from Source

An alternative strategy involves building every npm package from verifiable upstream source code rather than downloading artifacts from npm. Chainguard Libraries for JavaScript demonstrates this approach, discovering that for 98.5% of malicious packages, the malware was not present in the upstream source code—only in the published artifact.

This means building from source could reduce attack surface by approximately 98.5%, based on past data, because the repository would never publish the malicious versions available on npm.

The Swiss Cheese Model of Security

The most secure approach combines multiple layers: using Chainguard Libraries, applying the recommendations above, and maintaining awareness of ongoing risks. Each measure addresses different attack vectors, creating a more robust defense against supply-chain compromises.

The npm authentication overhaul represents important progress, but until short-lived, identity-bound credentials become the norm and MFA bypass is no longer required for automation, supply-chain risk from compromised build systems remains materially present.