{“lastseen”:”2026-02-13T11:13:02″,”description”:”\\n\\nIn December 2025, in response to the Sha1-Hulud incident, npm completed a major authentication overhaul intended to reduce supply-chain attacks. While the overhaul is a solid step forward, the changes don\u2019t make npm projects immune from supply-chain attacks. npm is still susceptible to malware attacks \u2013 here\u2019s what you need to know for a safer Node community.\\n\\n## **Let\u2019s start with the original problem**\\n\\nHistorically, npm relied on classic tokens: long-lived, broadly scoped credentials that could persist indefinitely. If stolen, attackers could directly publish malicious versions to the author\u2019s packages (no publicly verifiable source code needed). This made npm a prime vector for supply-chain attacks. Over time, numerous real-world incidents demonstrated this point. Shai-Hulud, Sha1-Hulud, and chalk\/debug are examples of recent, notable attacks.\\n\\n## **npm\u2019s solution**\\n\\nTo address this, npm made the following changes:\\n\\n 1. npm revoked all classic tokens and defaulted to session-based tokens instead. The npm team also improved token management. Interactive workflows now use short-lived session tokens (typically two hours) obtained via npm login, which _defaults_ to MFA for publishing. \\n 2. The npm team also encourages OIDC Trusted Publishing, in which CI systems obtain short-lived, per-run credentials rather than storing secrets at rest.\\n\\n\\n\\nIn combination, these practices improve security. They ensure credentials expire quickly and require a second factor during sensitive operations.\\n\\n## **Two important issues remain**\\n\\nFirst, people need to remember that the original attack on tools like ChalkJS was a successful MFA phishing attempt on npm\u2019s console. If you look at the original email attached below, you can see it was an MFA-focused phishing email (nothing like trying to do the right thing and still getting burned). The campaign tricked the maintainer into sharing both the user login and one-time password. This means in the future, similar emails could get short-lived tokens, which still give attackers enough time to upload malware (since that would only take minutes).\\n\\n\\n\\nSecond, MFA on publish is optional. Developers can still create 90-day tokens with MFA bypass enabled in the console, which are extremely similar to the classic tokens from before.\\n\\nThese tokens allow you to read and write to a token author\u2019s maintained packages. This means that if bad actors gain access to a maintainer\u2019s console with these token settings, they can publish new, malicious packages (and versions) on that author\u2019s behalf. This circles us back to the original issue with npm before they adjusted their credential policies.\\n\\nTo be clear, more developers using MFA on publish is good news, and future attacks should be fewer and smaller. However, making OIDC and MFA on-publish _optional_ still leaves the core issue unresolved.\\n\\nIn conclusion, if (1) MFA phishing attempts to npm\u2019s 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 risks that still exist.\\n\\n## **Recommendations**\\n\\nIn the spirit of open source security, here are three recommendations that we hope GitHub and npm will consider in the future.\\n\\n 1. Ideally, they continue to push for the ubiquity of OIDC in the long term. OIDC is very hard to compromise and would almost completely erase the issues surrounding supply-chain attacks.\\n 2. More realistically, enforcing MFA for local package uploads (either via an email code or a one-time password) would further reduce the blast radius of worms like Shai-Hulud. In other words, it would be an improvement to _not allow_ custom tokens that bypass MFA.\\n 3. At a minimum, it would be nice to add metadata to package releases, so developers can take precautions and avoid packages (or maintainers) who do not take supply chain security measures.\\n\\n\\n\\nIn short, npm has taken an important step forward by eliminating permanent tokens and improving defaults. Until short-lived, identity-bound credentials become the norm \u2014 and MFA bypass is no longer required for automation \u2014 supply-chain risk from compromised build systems remains materially present.\\n\\n## **A new way to do it**\\n\\nThis entire time, we\u2019ve been talking about supply-chain attacks by uploading packages to npm on a maintainer\u2019s behalf. If we could build every npm package from verifiable upstream source code rather than downloading the artifact from npm, we\u2019d be better off. That\u2019s exactly what Chainguard does for its customers with Chainguard Libraries for JavaScript.\\n\\nWe\u2019ve looked at the public database for compromised packages across npm and discovered that for 98.5% of malicious packages, the malware was not present in the upstream source code (just the published artifact). This means an approach of building from source would reduce your attack surface by some 98.5%, based on past data, because Chainguard\u2019s JavaScript repository would never publish the malicious versions available on npm.\\n\\nIn an ideal world, customers are most secure when they use Chainguard Libraries and apply the recommendations above. Per the \u201cSwiss cheese model of security,\u201d all of these features are layers of additive security measures, and companies would be best off using a combination of them.\\n\\nIf you\u2019d like to learn more about Chainguard Libraries for JavaScript, reach out to our team.\\n\\n**Note:** _This article was thoughtfully written and contributed for our audience by Adam La Morre, Senior Solutions Engineer at Chainguard._\\n\\nFound this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.\\n”,”published”:”2026-02-13T10:45:00″,”modified”:”2026-02-13T11:09:12″,”type”:”thn”,”title”:”npm\u2019s Update to Harden Their Supply Chain, and Points to Consider”,”source”:””,”references”:””,”id”:”THN:77BDB500253B979F77D8EAF7CBA64D05″,”bulletinFamily”:”info”,”cwe”:null,”cvelist”:[],”sourceData”:””,”sourceHref”:””,”cvss”:{“score”:0,”severity”:”NONE”,”vector”:”NONE”,”version”:”NONE”},”cvss2″:{},”cvss3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””,”cvssV3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””}},”href”:”https:\/\/thehackernews.com\/2026\/02\/npms-update-to-harden-their-supply.html”,”category_name”:”News”,”post_link”:””,”product”:””,”version”:””,”vendor”:””,”ai_description”:””,”ai_severity”:””,”ai_vendor”:””,”ai_product”:””,”ai_version”:””,”ai_score”:0}<\/p>\n","protected":false},"excerpt":{"rendered":"
{“lastseen”:”2026-02-13T11:13:02″,”description”:”\\n\\nIn December 2025, in response to the Sha1-Hulud incident, npm completed a major authentication overhaul intended to reduce supply-chain attacks. While the overhaul is a…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[6,8,12,13,33,7,11,43,5],"class_list":["post-40742","post","type-post","status-publish","format-standard","hentry","category-category_news","tag-cve","tag-cvss","tag-exploit","tag-news","tag-none","tag-security","tag-tapic","tag-thn","tag-vulnerability"],"yoast_head":"\n