In December 2025, in response to the Sha1-Hulud incident, npm completed a major overhaul of its authentication process aimed at reducing supply chain attacks. While the overhaul is a significant step forward, the changes do not make npm projects immune to supply chain attacks. npm remains vulnerable to malware attacks – here’s what you need to know for a more secure Node community.
See also: Lazarus campaign plants malicious npm and PyPI packages
Historically, npm relied on classic tokens: long-lived, broad-scope credentials that could last indefinitely. If stolen, attackers could directly publish malicious versions to the author's packages without the need for publicly verifiable source code. This made npm a prime target for supply chain attacks. Several real-world incidents, such as Shai-Hulud, Sha1-Hulud, and chalk/debug, demonstrated this vulnerability.
npm has deprecated all classic tokens and adopted session-based tokens as the default. The npm team has also improved token management. Interactive workflows now use short-lived session tokens (typically two hours) obtained through npm login, which defaults to using MFA for publishing.
The npm team encourages the use of OIDC Trusted Publishing, where CI systems acquire short-lived credentials per execution rather than storing secrets at rest. These practices improve security by ensuring that credentials expire quickly and requiring a second factor during sensitive operations.
See also: Compromised dYdX packages on npm and PyPI distribute wallet thieves and RATs
However, two important issues remain. First, the initial attack on tools like ChalkJS was a successful MFA phishing attempt on the npm console. The campaign tricked the maintainer into sharing both their username and one-time password. This means that in the future, similar phishing emails could lead to short-lived tokens, giving attackers plenty of time to upload malware.
Second, MFA on publish is optional. Developers can still create 90-day tokens with MFA bypass enabled in the console, which are similar to the classic tokens from before. These tokens allow access to packages maintained by the token author, meaning that if malicious users gain access to a maintainer's console with these token settings, they can publish new, malicious packages on behalf of that author.
This goes back to the original problem with npm before they adjusted their credential policies.
More developers using MFA on publish is good news, and future attacks should be fewer and smaller. However, the fact that OIDC and MFA on publish are optional leaves the core problem unsolved.
See also: Vulnerabilities in npm and yarn platforms allow bypass of Shai-Hulud defenses
In conclusion, if MFA phishing attempts on the npm console still work and access to the console equates to access to publish new packages/versions, developers need to be aware of the supply chain risks that still exist.
🔒 Protect your privacy with Proton VPN
Swiss VPN from the creators of Proton Mail — strict no-logs policy, strong encryption, and built-in NetShield that blocks ads, trackers, & malware.
- ✔ No-logs, based in Switzerland (except 14-Eyes)
- ✔ NetShield: blocks ads, trackers & malicious domains
- ✔ Covers all devices — free version available
The link is an affiliate link — SecNews may receive a commission at no additional cost to you. It does not affect the independence of our article writing.
