In the ever-evolving landscape of software development, the integrity of our supply chains is paramount. The Node.js ecosystem, powered by npm, has long been a critical component, but also a significant target for malicious actors. In December 2025, following incidents like Sha1-Hulud, npm rolled out a substantial authentication overhaul aimed at fortifying its defenses against supply-chain attacks. While this represents a commendable leap forward, it’s crucial for the Node community to understand that these changes, while robust, do not render npm projects entirely immune. Malware attacks remain a tangible threat, and a deeper understanding of the current security posture is essential for a safer future.
The Root of the Problem: Classic Tokens and Their Peril
Historically, npm’s security architecture was built upon classic tokens – long-lived, broadly scoped credentials that could persist indefinitely. This design presented a glaring vulnerability: if stolen, these tokens granted attackers unfettered access to publish malicious versions directly to an author’s packages, often without the need for publicly verifiable source code. This made npm an attractive vector for supply-chain attacks, a reality underscored by numerous real-world incidents. Notorious examples such as Shai-Hulud, Sha1-Hulud, and the Chalk/Debug attacks served as stark reminders of the profound risks inherent in this token-based system.
npm’s Countermeasures: A Step Towards Stronger Security
In response to these escalating threats, npm implemented a series of critical changes:
Revoking Classic Tokens and Embracing Session-Based Credentials
A cornerstone of the overhaul was the revocation of all classic tokens. npm now defaults to session-based tokens, significantly reducing the window of opportunity for attackers. Interactive workflows, such as those initiated via npm login, now generate short-lived session tokens, typically valid for just two hours. Crucially, publishing operations through these workflows now default to requiring Multi-Factor Authentication (MFA).
Encouraging OIDC Trusted Publishing
Beyond individual developer workflows, the npm team is actively championing OIDC (OpenID Connect) Trusted Publishing. This innovative approach allows Continuous Integration (CI) systems to obtain short-lived, per-run credentials, eliminating the need to store sensitive secrets at rest. Together, these practices represent a significant security uplift, ensuring credentials expire rapidly and demanding a second factor for sensitive operations, thereby making it substantially harder for attackers to maintain persistent access.
Lingering Vulnerabilities: Where the Chain Still Frays
Despite these significant advancements, two critical issues persist, reminding us that vigilance remains paramount:
The Persistent Threat of MFA Phishing
It’s vital to recall that the original attack on popular tools like ChalkJS wasn’t due to a flaw in npm’s token system per se, but rather a successful MFA phishing attempt targeting npm’s console. Attackers tricked a maintainer into divulging both their login credentials and a one-time password. This means that even with short-lived tokens, a sophisticated phishing campaign could still grant attackers enough time – mere minutes – to upload malicious packages. The human element, unfortunately, remains a potential weak link.
The Optionality of MFA and 90-Day Tokens
A second, equally concerning issue is that MFA on publish remains optional. Developers retain the ability to create 90-day tokens with MFA bypass enabled directly within the console. These tokens bear a striking resemblance to the problematic classic tokens of old, granting read and write access to a token author’s maintained packages. Should bad actors gain access to a maintainer’s console configured with these settings, they could still publish new, malicious packages and versions on that author’s behalf, effectively circling back to the very vulnerabilities npm sought to eliminate. While increased MFA adoption is undoubtedly positive, the optional nature of both OIDC and MFA on publish leaves a fundamental gap in the security posture.
Charting a Safer Course: Recommendations for the Future
In the spirit of open-source security, several recommendations could further harden the npm supply chain:
The Promise of Ubiquitous OIDC
Ideally, npm and GitHub would continue to advocate for and eventually enforce the ubiquity of OIDC. Its inherent difficulty to compromise could almost entirely neutralize the issues surrounding supply-chain attacks stemming from compromised credentials.
Enforcing MFA for Local Package Uploads
More realistically, enforcing MFA for all local package uploads – whether via an email code or a one-time password – would significantly reduce the “blast radius” of future incidents akin to Shai-Hulud. Prohibiting custom tokens that bypass MFA is a crucial step in this direction.
Enhanced Metadata for Package Releases
At a minimum, adding robust metadata to package releases would empower developers. This metadata could highlight maintainers who adopt strong supply chain security measures, allowing consumers to make informed decisions and avoid packages from less secure sources.
In essence, npm has made a vital stride by phasing out permanent tokens and enhancing default security settings. However, until short-lived, identity-bound credentials become the universal norm, and MFA bypass options for automation are eliminated, the risk of supply-chain compromise from build systems will remain a material concern.
A Paradigm Shift: Building from Source with Chainguard
While the focus has largely been on preventing unauthorized package uploads, an alternative approach offers a radical reduction in attack surface: building every npm package from verifiable upstream source code rather than relying solely on downloaded artifacts from npm. This is precisely the philosophy behind Chainguard Libraries for JavaScript.
Chainguard’s analysis of public databases for compromised npm packages revealed a compelling statistic: for 98.5% of malicious packages, the malware was absent from the upstream source code, present only in the published artifact. This means that an approach centered on building from source could reduce the attack surface by approximately 98.5%, based on historical data. Chainguard’s JavaScript repository, by building from trusted source, would inherently never publish these malicious versions found on npm, offering customers a significantly more secure dependency chain.
For more details, visit our website.
Source: Link
Leave a comment