npm’s Update to Harden Their Supply Chain, and Points to Consider

Source: The Hacker News

Overview

In December 2025, in response to the Sha1‑Hulud incident, npm completed a major authentication overhaul intended to reduce supply‑chain attacks. While the overhaul is a solid step forward, the changes don’t make npm projects immune from supply‑chain attacks. npm is still susceptible to malware attacks – here’s what you need to know for a safer Node community.

Let’s Start with the Original Problem

Historically, npm relied on classic tokens—long‑lived, broadly scoped credentials that could persist indefinitely. If these tokens were stolen, attackers could publish malicious versions of the author’s packages without needing any publicly verifiable source code. This made npm a prime vector for supply‑chain attacks.

Over time, numerous real‑world incidents have demonstrated this vulnerability. Notable recent examples include:

• Shai‑Hulud
• Sha1‑Hulud
• chalk/debug

These attacks underscore the critical need for more secure authentication mechanisms in the npm ecosystem.

npm’s solution

To address the security concerns, npm introduced several key changes:

• Token revocation and session‑based authentication

  • All classic tokens were revoked.
  • npm now defaults to short‑lived session tokens (typically ≈ 2 hours) obtained via npm login.
  • Publishing via the interactive workflow defaults to MFA.

• Encouragement of OIDC Trusted Publishing

  • CI systems can obtain short‑lived, per‑run credentials instead of storing long‑term secrets.

These practices together improve security by:

1. Ensuring credentials expire quickly.
2. Requiring a second factor for sensitive operations such as publishing.

Two Important Issues Remain

1. Ongoing MFA‑phishing risk

• The original attack on tools such as ChalkJS began with a successful MFA‑phishing email targeting npm’s console.
• The phishing message (see the original email below) asked the maintainer to provide both the user login and a one‑time password (OTP).
• Once the attacker obtained the short‑lived OTP, they could upload malicious code within minutes.

Original phishing email (excerpt)
“We noticed unusual activity on your npm account. Please confirm your identity by entering your login credentials and the OTP sent to your device.”

Because the OTP is only valid for a brief window, attackers can still exploit it to publish malicious packages quickly.

2. MFA on publish is still optional

• Developers can create 90‑day tokens with MFA bypass enabled directly in the npm console.
• These tokens behave like the classic long‑lived tokens: they grant read and write access to every package the token’s author maintains.
• If an attacker gains console access with such a token, they can publish new, malicious versions under the author’s name—re‑creating the same supply‑chain vulnerability that existed before npm tightened its credential policies.

Why This Matters

• More developers adopting MFA on publish is a positive step, and it should reduce the frequency and impact of future attacks.
• However, because OIDC and MFA‑on‑publish remain optional, the fundamental risk of credential‑based supply‑chain compromise persists.

Bottom Line

If:

1. MFA‑phishing attempts against npm’s console still succeed, and
2. Console access equals the ability to publish new packages/versions,

then developers must remain vigilant about the remaining supply‑chain risks. Enforcing MFA (and OIDC) for publishing should become a mandatory security baseline, not an optional feature.

Recommendations

In the spirit of open‑source security, we propose three actions for GitHub and npm to consider:

1. Promote OIDC adoption – Continue pushing for the widespread use of OpenID Connect. OIDC is extremely difficult to compromise and would largely eliminate many supply‑chain attack vectors.

2. Enforce MFA for package uploads – Require multi‑factor authentication (via email code, one‑time password, etc.) for all local package publications. This would reduce the blast radius of threats such as Shai‑Hulud and prevent the use of custom tokens that bypass MFA.

3. Add security metadata to releases – Include explicit metadata (e.g., MFA status, token type, security certifications) with each package release so developers can identify and avoid packages—or maintainers—who do not follow best supply‑chain security practices.

npm’s recent move to eliminate permanent tokens and improve default settings is a significant step forward. However, until short‑lived, identity‑bound credentials become the norm and MFA bypass is no longer required for automation, the risk from compromised build systems will remain materially present.

A New Way to Do It

We’ve been discussing supply‑chain attacks that involve uploading malicious packages to npm on a maintainer’s behalf. If we built every npm package from a verifiable upstream source instead of downloading the published artifact, we’d dramatically reduce risk. That’s exactly what Chainguard Libraries for JavaScript provides for its customers.

• Key insight: In a review of the public database of compromised npm packages, Chainguard’s analysis found that 98.5 % of malicious packages contained malware only in the published artifact, not in the upstream source code.
• Result: Building from source would cut the attack surface by roughly 98.5 % based on historical data, because Chainguard’s repository never publishes the malicious versions that appear on npm.

Why This Matters

In an ideal world, customers achieve the highest security by:

1. Using Chainguard Libraries to fetch verified source builds.
2. Applying the additional recommendations outlined in the “Swiss cheese model of security,” where each layer adds protection.

Combining these measures gives organizations the strongest possible defense.

Learn More

If you’d like to explore Chainguard Libraries for JavaScript further, reach out to our team.

Note: This article was thoughtfully written and contributed by Adam La Morre, Senior Solutions Engineer at Chainguard.

Enjoyed this piece?

Follow us for more exclusive content:

• Google News
• Twitter
• LinkedIn