npm Review for Strengthening Their Supply Chain, and Points to Consider
In December 2025, in response to the Sha1-Hulud incident, npm completed a major validation aimed at reducing supply chain attacks. While the fix is a solid step forward, the changes do not make npm projects immune to supply chain attacks. npm is still vulnerable to malware attacks – here’s what you need to know about the safe Node community.
Let’s start with the first problem
Historically, npm has relied on primitive tokens: long-lived, scoped credentials that can last forever. If stolen, attackers can directly publish malicious versions of the author’s packages (no publicly verified source code required). This makes npm a prime vector for supply chain attacks. Over time, many real-world events illustrated this point. Shai-Hulud, Sha1-Hulud, and chalk/debug are examples of recent, notable attacks.
The npm solution
To address this, npm makes the following changes:
- npm has deprecated all old tokens and converted to session based tokens instead. The npm team also improved token management. Interactive workflows now use short-lived tokens (typically two hours) obtained via npm login, which automatic in MFA for publication.
- The npm team also promotes OIDC Trusted Publishing, where CI systems receive temporary credentials, which are run regularly rather than storing secrets at rest.
Together, these processes improve security. They ensure that credentials expire quickly and require a second feature during critical operations.
Two important issues remain
First, people need to remember that the original attack on tools like ChalkJS was a successful MFA phishing attempt on the npm console. If you look at the original email attached below, you can see that it was an MFA focused phishing email (nothing like trying to do the right thing but still getting burned). The campaign tricked the custodian into sharing the user’s login and one-time password. This means that in the future, the same emails can receive temporary tokens, which still gives the attackers enough time to upload the malware (since that can only take minutes).
Second, an MFA in publishing is optional. Developers can still create 90-day tokens with MFA bypass enabled on the console, very similar to legacy tokens.
These tokens allow you to read and write to the token writer’s stored packages. This means that if bad actors gain access to the maintainer’s console with these token settings, they can publish new, malicious packages (and versions) instead of that author. This takes us back to the original npm issue before they fixed their authentication policies.
To be clear, more developers using MFA in publishing is good news, and future attacks should be fewer and fewer. However, doing OIDC and MFA is published by choice it still leaves the core issue unresolved.
In conclusion, if (1) MFA phishing attempts to make the npm 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 vulnerabilities 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.
- Accordingly, they continue to push the OIDC universe in the long term. OIDC is very difficult to compromise and will almost completely erase issues related to supply chain attacks.
- Honestly, enforcing MFA on local package uploads (either via an email code or a one-time password) will greatly reduce the outbreak of worms like Shai-Hulud. In other words, it could be better do not allow custom tokens bypass MFA.
- At the very least, it would be good to add metadata to the package release, so developers can take security measures and avoid packages (or maintainers) that don’t take supply chain security measures.
In short, npm has taken a significant step forward by removing permanent tokens and improving automation. Until the short term, ID-bound credentials become the norm – and MFA bypass is no longer required to automate – the risk of supply chain sales from compromised manufacturing systems remains.
A new way of doing it
All along, we’ve been talking about supply chain attacks by uploading packages to npm on behalf of the maintainer. If we could build each npm package from upstream unverifiable source code rather than downloading an artifact from npm, we would be better off. That’s exactly what Chainguard does for its customers with Chainguard Libraries for JavaScript.
We looked at the public database of malicious packages across npm and found that in 98.5% of malicious packages, the malware was not in the upstream source code (just a published artifact). This means that the build-from-source approach can reduce your attack surface by about 98.5%, based on previous data, because Chainguard’s JavaScript repository will never publish malicious versions available in npm.
In an ideal world, customers are more secure if they use Chainguard Libraries and use the recommendations above. In the “Swiss cheese security model,” all of these features are layers of additional security measures, and companies would be better off using a combination of them.
If you would like to learn more about Chainguard Libraries for JavaScript, contact our team.
Note: This article was carefully written and contributed to our audience by Adam La Morre, Senior Solutions Engineer at Chainguard.
