In December 2025, in response to the Sha1-Hulud incident, npm completed a major certification review aimed at reducing supply chain attacks. While this overhaul is a solid step forward, this change does not make npm projects immune to supply chain attacks. npm remains 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: credentials that can last indefinitely, are long-lived, and have wide scope. If stolen, an attacker could publish a malicious version directly in the author’s package (no publicly verifiable source code required). This has made npm a major vector for supply chain attacks. Over time, numerous real-world incidents have demonstrated this point. Shai-Hulud, Sha1-Hulud, and choke/debug are recent examples of notable attacks.
npm solution
To address this, npm has made the following changes:
npm has revoked all classic tokens and defaulted to session-based tokens instead. The npm team has also improved token management. Interactive workflows now use short-lived session tokens (typically 2 hours) obtained via npm login. Publishing uses MFA by default. The npm team also encourages OIDC Trusted Publishing, where CI systems retrieve short-lived credentials for each run rather than storing secrets.
Combining these will improve security. These allow credentials to expire quickly and require a second factor during sensitive operations.
Two important questions remain
First, it’s important to remember that the first attacks against tools like ChalkJS were successful MFA phishing attempts on the npm console. If you look at the original email attached below, you’ll see that it’s a phishing email focused on MFA (don’t get flamed if you’re trying to do the right thing). The campaign tricked administrators into sharing both user logins and one-time passwords. This means that in the future, similar emails may obtain short-lived tokens, but still give attackers enough time to upload malware (as this only takes a few minutes).
Second, MFA when publishing is optional. Developers can create 90-day tokens with MFA bypass enabled in the console. This is very similar to the previous classic token.
These tokens allow you to read and write packages managed by the token creator. This means that once a malicious party gains access to a maintainer’s console using these token settings, they can publish new malicious packages (and versions) on behalf of their authors. This goes back to the original problem with npm before adjusting the credential policy.
Make no mistake: More developers using MFA when publishing is good news, and should lead to fewer and smaller attacks in the future. However, making OIDC and MFA optional at the time of publication leaves the core issue unresolved.
In conclusion, developers need to be aware of the supply chain risks that still exist if (1) MFA phishing is to keep npm’s console working, and (2) console access is equivalent to access to publish new packages/versions.
Recommendations
In the spirit of open source security, here are three recommendations that I hope GitHub and npm consider in the future.
Ideally, they will continue to promote OIDC adoption over the long term. OIDC is extremely difficult to compromise and almost completely eliminates the problems surrounding supply chain attacks. More realistically, enforcing MFA on local package uploads (via email codes or one-time passwords) further reduces the explosive radius of worms like Shai-Hulud. That is, the improvement is to disallow custom tokens that bypass MFA. At the very least, it’s a good idea to add metadata to package releases so that developers can take precautions and avoid packages (or maintainers) that don’t have supply chain security measures in place.
In short, npm has taken an important step by eliminating persistent tokens and improving defaults. Until short-lived, identity-associated credentials become the norm and automation no longer requires MFA bypass, supply chain risks from compromised build systems will remain substantial.
new way
All this time we’ve been talking about supply chain attacks by uploading packages to npm on behalf of maintainers. It would be better if all npm packages could be built from verifiable upstream source code, rather than downloading artifacts from npm. That’s exactly what Chainguard is doing for its customers with the Chainguard library for JavaScript.
We examined the public database of compromised packages across npm and found that for 98.5% of malicious packages, the malware was not present in the upstream source code (only in the public artifacts). This means that our build-from-source approach reduces the attack surface by approximately 98.5%, based on historical data, as Chainguard’s JavaScript repository does not expose malicious versions available on npm.
In an ideal world, customers would be most secure when using the Chainguard library and applying the recommendations above. According to the “Swiss Cheese Model of Security,” all of these features are additional layers of security measures, and businesses are best able to use them in conjunction.
If you would like to learn more about the Chainguard library for JavaScript, please contact our team.
Note: This article was thoughtfully written and contributed to our readers by Adam La Morre, Senior Solutions Engineer at Chainguard.
Source link
