In December 2025, in response to the Sha1-Hulud incident, npm accomplished a significant authentication overhaul supposed to scale back supply-chain assaults. Whereas the overhaul is a stable step ahead, the modifications don’t make npm tasks immune from supply-chain assaults. npm remains to be vulnerable to malware assaults – right here’s what you might want to know for a safer Node group.
Let’s begin with the unique drawback
Traditionally, npm relied on basic tokens: long-lived, broadly scoped credentials that would persist indefinitely. If stolen, attackers may instantly publish malicious variations to the creator’s packages (no publicly verifiable supply code wanted). This made npm a major vector for supply-chain assaults. Over time, quite a few real-world incidents demonstrated this level. Shai-Hulud, Sha1-Hulud, and chalk/debug are examples of current, notable assaults.
npm’s resolution
To handle this, npm made the next modifications:
- npm revoked all basic tokens and defaulted to session-based tokens as an alternative. The npm crew additionally improved token administration. Interactive workflows now use short-lived session tokens (sometimes two hours) obtained by way of npm login, which defaults to MFA for publishing.
- The npm crew additionally encourages OIDC Trusted Publishing, wherein CI techniques acquire short-lived, per-run credentials reasonably than storing secrets and techniques at relaxation.
Together, these practices enhance safety. They guarantee credentials expire rapidly and require a second issue throughout delicate operations.
Two essential points stay
First, folks must keep in mind that the unique assault on instruments like ChalkJS was a profitable MFA phishing try on npm’s console. Should you have a look at the unique e-mail hooked up beneath, you may see it was an MFA-focused phishing e-mail (nothing like attempting to do the fitting factor and nonetheless getting burned). The marketing campaign tricked the maintainer into sharing each the consumer login and one-time password. This implies sooner or later, comparable emails may get short-lived tokens, which nonetheless give attackers sufficient time to add malware (since that will solely take minutes).
Second, MFA on publish is optional. Developers can still create 90-day tokens with MFA bypass enabled in the console, which are extremely similar to the classic tokens from before.
These tokens allow you to read and write to a token author’s maintained packages. This means that if bad actors gain access to a maintainer’s console with these token settings, they can publish new, malicious packages (and versions) on that author’s behalf. This circles us back to the original issue with npm before they adjusted their credential policies.
To be clear, more developers using MFA on publish is good news, and future attacks should be fewer and smaller. However, making OIDC and MFA on-publish optional still leaves the core issue unresolved.
In conclusion, if (1) MFA phishing attempts to npm’s console still work and (2) access to the console equals access to publish new packages/versions, then developers need to be aware of the supply-chain risks that still exist.
Recommendations
In the spirit of open source security, here are three recommendations that we hope GitHub and npm will consider in the future.
- Ideally, they continue to push for the ubiquity of OIDC in the long term. OIDC is very hard to compromise and would almost completely erase the issues surrounding supply-chain attacks.
- More realistically, enforcing MFA for local package uploads (either via an email code or a one-time password) would further reduce the blast radius of worms like Shai-Hulud. In other words, it would be an improvement to not allow custom tokens that bypass MFA.
- At a minimum, it would be nice to add metadata to package releases, so developers can take precautions and avoid packages (or maintainers) who do not take supply chain security measures.
In short, npm has taken an important step forward by eliminating permanent tokens and improving defaults. 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.
A new way to do it
This entire time, we’ve been talking about supply-chain attacks by uploading packages to npm on a maintainer’s behalf. If we could build every npm package from verifiable upstream source code rather than downloading the artifact from npm, we’d be better off. That’s exactly what Chainguard does for its customers with Chainguard Libraries for JavaScript.
We’ve looked at the public database for compromised packages across npm and discovered that for 98.5% of malicious packages, the malware was not present in the upstream source code (just the published artifact). This means an approach of building from source would reduce your attack surface by some 98.5%, based on past data, because Chainguard’s JavaScript repository would never publish the malicious versions available on npm.
In an ideal world, customers are most secure when they use Chainguard Libraries and apply the recommendations above. Per the “Swiss cheese model of security,” all of these features are layers of additive security measures, and companies would be best off using a combination of them.
If you’d like to learn more about Chainguard Libraries for JavaScript, reach out to our team.
Note: This article was thoughtfully written and contributed for our audience by Adam La Morre, Senior Solutions Engineer at Chainguard.
