The npm ecosystem, a critical component of the JavaScript and Node.js development community, experienced a significant security incident known as Sha1-Hulud, which exposed vulnerabilities in its authentication and package publishing processes. Historically, npm used long-lived, broadly scoped classic tokens that, if stolen, allowed attackers to publish malicious package versions without publicly verifiable source code. This made npm a prime target for supply-chain attacks, as demonstrated by multiple real-world incidents including Sha1-Hulud and attacks on popular packages like ChalkJS. In response, npm completed a major overhaul in December 2025, revoking all classic tokens and shifting to short-lived session tokens (typically two hours) obtained via npm login, which defaults to multi-factor authentication (MFA) for publishing. Additionally, npm encourages the use of OpenID Connect (OIDC) Trusted Publishing, enabling CI systems to obtain short-lived, per-run credentials rather than storing secrets at rest. These changes significantly improve security by limiting token lifespan and requiring a second authentication factor during sensitive operations. However, two critical issues persist: first, MFA phishing attacks remain effective, as attackers can trick maintainers into revealing both login credentials and one-time passwords, allowing short-lived tokens to be misused to publish malware quickly. Second, MFA on publish is optional, and developers can create 90-day tokens with MFA bypass enabled, which closely resemble the old classic tokens. If attackers gain access to such tokens, they can publish malicious packages on behalf of maintainers, perpetuating the original supply-chain risk. The article recommends that npm and GitHub enforce MFA without bypass options, promote universal adoption of OIDC, and add metadata to package releases to help developers identify maintainers who follow supply-chain security best practices. Furthermore, building npm packages from verifiable upstream source code, as done by solutions like Chainguard Libraries, could reduce the attack surface by approximately 98.5%, since most malware is injected post-source code. Overall, while npm’s authentication overhaul is a significant step forward, supply-chain risks remain due to optional MFA enforcement and phishing vulnerabilities, necessitating continued vigilance and layered security approaches.

For European organizations, the npm supply-chain remains a critical attack vector due to the widespread use of Node.js and JavaScript in enterprise applications, web services, and internal tooling. A successful compromise of maintainer credentials or CI pipelines could lead to the distribution of malicious code within trusted packages, potentially resulting in data breaches, system compromise, or disruption of services. The optional nature of MFA on publish and the existence of long-lived tokens with MFA bypass increase the risk that attackers can inject malware rapidly after credential theft. This threat is particularly impactful for organizations with large development teams or those relying heavily on open-source npm packages, as malicious updates can propagate quickly across multiple projects and environments. Additionally, phishing campaigns targeting developers remain a persistent risk, potentially undermining the security improvements. The supply-chain attack vector could also affect regulatory compliance, especially under GDPR, if malicious code leads to data leakage or unauthorized access. European organizations must therefore consider supply-chain security as a critical component of their cybersecurity posture, integrating secure development practices, credential hygiene, and continuous monitoring to mitigate these risks.

1. Enforce mandatory MFA for all npm publishing operations without allowing MFA bypass tokens to be created or used. 2. Adopt and mandate OIDC Trusted Publishing workflows in CI/CD pipelines to use short-lived, per-run credentials instead of stored tokens. 3. Implement phishing-resistant MFA methods such as hardware security keys or app-based authenticators to reduce the risk of credential theft. 4. Integrate supply-chain security tools that verify package provenance and metadata, enabling detection of maintainers who do not follow security best practices. 5. Prefer building npm packages from verifiable upstream source code rather than relying solely on published artifacts, leveraging solutions like Chainguard Libraries or similar. 6. Conduct regular security awareness training for developers focused on phishing risks and secure token management. 7. Monitor npm account activity and token usage for anomalous behavior indicative of compromise. 8. Collaborate with npm and GitHub to push for policy changes that eliminate long-lived tokens and enforce stricter authentication controls. 9. Use dependency scanning and software composition analysis tools to detect malicious or suspicious package versions before deployment. 10. Establish incident response plans specifically addressing supply-chain compromise scenarios to enable rapid containment and remediation.