The Weakest Link in the Digital Chain
In the contemporary software development landscape, where speed and code reusability are paramount, the Node Package Manager (NPM) has become an indispensable pillar of the JavaScript ecosystem. Acting as the world’s largest open-source library repository, with over 3 million packages and billions of weekly downloads, NPM simplifies dependency management and significantly accelerates the development lifecycle.¹ It enables developers to build upon pre-existing components to construct complex applications, from websites to development tools.² Paradoxically, it is this ubiquity and interconnectedness that transforms the repository into a prime target for cybercriminals, whose exploitation can lead to exponential repercussions.
The escalation of threats on NPM is part of a broader context of software supply chain attacks. Unlike a direct attack on a company, this type of threat targets a supplier or a link in the production chain—in this case, the code repository—to indirectly infiltrate a large number of downstream customers.³ This strategic approach allows attackers to bypass traditional perimeter defenses and optimize their efforts for maximum cascading effect.⁵ Recent data confirm the severity of this trend, with a notable increase in the frequency and sophistication of attacks.⁶ Forecasts estimate the annual damages related to these attacks at $138 billion by 2031, highlighting their systemic economic impact.⁶ The heavy reliance on open-source components and the growing automation of Continuous Integration and Continuous Deployment (CI/CD) pipelines have created a fertile ground for the large-scale propagation of malware, turning the NPM repository into a mass distribution vector.⁸
The year 2025 marks a significant turning point in this threat, illustrated by two major incidents that occurred in quick succession in September. These events are not mere isolated occurrences but a reflection of a professional and diversified threat that exploits not only technical flaws but also human vulnerabilities and ecosystem processes. The first incident, dubbed the debug/chalk attack, revealed the effectiveness of targeted social engineering. A sophisticated phishing campaign targeted package maintainers by sending them fake NPM support emails, asking them to “update” their two-factor authentication (2FA) on a fake domain, npmjs.help.¹⁰ Despite the maintainers having 2FA enabled, the attack successfully stole their credentials and TOTP codes, allowing the hackers to take control of the accounts.⁹ They then injected malicious code into 18 popular packages, including the debug and chalk libraries, which account for billions of weekly downloads.¹⁰ The malware’s payload operated exclusively in browser environments, intercepting web APIs for cryptocurrency transactions.⁹ Its sophisticated mechanism used a Levenshtein algorithm, a string similarity metric, to replace the victim’s wallet addresses with attacker-controlled addresses that were visually indistinguishable to an unsuspecting user.¹⁰
Shortly after, a second incident shook the community. The appearance of a self-replicating worm, named “Shai-Hulud,” marked a new phase of escalation. This threat, described as an evolution of previous attacks, was not limited to a single code injection. It stole authentication tokens for NPM and GitHub repositories, as well as access keys for cloud services (AWS, GCP).¹⁴ Once in possession of this information, the worm spread autonomously, injecting its own malicious code into other packages maintained by the victim and publishing new corrupted versions to the repository.¹⁴ The proliferation was exponential, affecting over 180 packages at the time of its initial detection, a number that has since surpassed 500.¹⁵ The worm’s modus operandi is particularly alarming, as it did not use traditional command-and-control servers for data exfiltration. Instead, it published the stolen secrets to public repositories on GitHub by creating new copies of private repositories with a -migration suffix.¹⁴ Furthermore, researchers observed that the worm’s design included the use of legitimate open-source tools like trufflehog for secret scanning on systems and assessed with moderate confidence that artificial intelligence was used to generate its malicious script, signaling an acceleration in the sophistication of threats.¹⁴
The analysis of these two simultaneous events reveals a multifaceted reality of the software supply chain threat. The debug/chalk attack highlights the growing importance of the human factor as the primary entry point, where social engineering successfully bypasses sophisticated technical protections like 2FA.⁹ On the other hand, the emergence of the Shai-Hulud worm indicates an evolution of threats towards autonomy and proliferation. This type of attack transforms the compromise of a single individual into a systemic threat capable of self-sustaining and spreading without the attacker’s continuous intervention, by exploiting a maintainer’s existing publishing privileges.¹⁵ In sum, these incidents demonstrate that the threat is no longer static; it learns, adapts, and exploits automation, implicit trust, and human weaknesses. This evolution underscores the urgency for the entire ecosystem to rethink security beyond traditional perimeter measures, recognizing that the code supply chain is only as strong as its weakest link.
Part I. Anatomy of Software Supply Chain Attacks on NPM
A. The Critical Role of Node.js and Its Package Ecosystem
The NPM package manager is inseparable from the Node.js runtime environment, acting as the backbone of modern web development.¹ Its role extends beyond simple library management; it is the central point for collaboration and code reuse, allowing developers to access millions of packages to accelerate their projects.² This efficiency relies on a model of interdependence where one package can call another, creating a complex and often nested dependency tree.¹⁰ A relatively simple and widely used package, like chalk or debug, can be a “transitive” dependency—that is, a dependency of a dependency—for thousands of applications.⁸ This interconnected structure creates a cascade effect, where the compromise of a single link, no matter how small, can silently spread to hundreds of downstream projects and organizations, turning a targeted attack into a widespread threat.⁸
B. Attack Vectors: A Detailed Typology
Attacks on NPM repositories are not limited to a single modus operandi. They exploit a variety of techniques, ranging from human manipulation to the exploitation of configuration flaws.
1. Account Compromise through Social Engineering (Phishing)
Targeted phishing is a particularly effective attack vector, as demonstrated by the debug/chalk attack of September 2025. The attackers registered a fake domain (npmjs.help) mimicking NPM’s legitimate infrastructure.¹¹ They then sent phishing emails to package maintainers, creating a sense of urgency by claiming that 2FA updates were required by a deadline.¹¹ One maintainer was deceived by the ruse and entered their username, password, and TOTP code on the fake site, allowing the attackers to take control of their account.¹⁰ This chain of events shows how an infrastructure’s security can be compromised not by a technical flaw, but by human error—the most unpredictable and often weakest factor in the supply chain. The fact that the attack succeeded even with two-factor authentication enabled illustrates the sophistication of social engineering, which can bypass technological security measures by directly targeting the user.⁹
2. Impersonation-Based Attacks (Typosquatting) and Human Errors (Dependency Confusion)
Two other major vectors exploit developer errors and the logic of package managers.
Typosquatting involves publishing malicious packages with names very similar to popular libraries (e.g., “lodas” instead of “lodash”).¹⁸ Attackers hope that a developer will make a typo during installation, thereby fetching the corrupted package instead of the legitimate version. Although simple, this technique remains effective and has led to the proliferation of hundreds of such packages on NPM.²¹
Dependency Confusion exploits a more subtle configuration flaw. It occurs when organizations use private package names that are identical to packages that could exist on the public repository.²² An attacker, after discovering the name of an internal package, can publish a malicious version of that package to the public registry with a higher version number.²³ By default, many package managers prefer the highest version number, and if the configuration is not strict, the automation system may download and install the malicious version instead of the internal, trusted one.²² The case of Microsoft in 2021 is an emblematic example of this vulnerability.²³
These two methods reveal a paradox: the implicit trust placed in the open-source ecosystem and the automation of processes can become the main attack vectors.
3. Exploitation of Publishing Mechanisms and Scripts
The Shai-Hulud worm of September 2025 illustrates the abuse of a legitimate mechanism: NPM package lifecycle scripts, particularly the postinstall phase.²⁴ This feature is designed to allow developers to execute arbitrary code after a dependency is installed. Attackers abused this function by inserting their payload into this script, which executes automatically on the developer’s system or in a CI/CD build environment as soon as the package is installed.¹⁴ This technique turns a convenience feature into an entry point for malicious code execution without any further interaction from the victim, thereby facilitating the worm’s proliferation and the theft of sensitive data.¹⁶
| Attack Vector | Modus Operandi | Recent Examples (2025) | Primary Targets |
| Phishing / Social Engineering | Targeted attack to steal credentials and 2FA codes. | debug/chalk attack¹⁰ | Package maintainers, developers. |
| Typosquatting | Publishing packages with misspelled names to deceive developers. | Typosquatting packages²¹ | Individual developers. |
| Dependency Confusion | Exploiting package manager logic to substitute an internal package with a malicious public version. | Microsoft case²³ | CI/CD systems, enterprises. |
| Abuse of Post-install Scripts | Injecting malicious code into package lifecycle scripts, which execute automatically. | Shai-Hulud worm¹⁴ | Developers, CI/CD systems. |
Part II. Recent Incidents (2025): Analysis of Major Case Studies
A. The September 2025 Attack on the debug and chalk Packages
The September 2025 incident involving the debug and chalk packages demonstrated a surgical and sophisticated attack scenario. The incident’s timeline is marked by its speed: the malicious versions were published on September 8 at 13:16 UTC and were removed from the repository just two hours later, at 15:20 UTC.¹⁰ Despite their brief availability, thousands of developers may have installed them in that interval.¹⁰ The payload was a JavaScript script designed exclusively for browser environments, meaning it did not directly target the operating system or local files, but rather the actions of end-users.¹⁰
The malware intercepted calls to web APIs and cryptocurrency wallets (window.ethereum, fetch, XMLHttpRequest).¹⁰ Its main objective was to rewrite transactions by replacing recipient addresses with attacker-controlled addresses.¹³ To do this, it used a Levenshtein algorithm to find visually similar addresses, making the substitution difficult for the user to detect.¹¹ Paradoxically, despite the perceived severity of the attack and the popularity of the affected packages, the direct financial impact was minimal, with only a few cents worth of cryptocurrency stolen in total.²⁵ This low return raises questions: was the attack merely a proof-of-concept, or was the real motivation disruption and a show of force? Several analyses suggest that the true cost of this incident was not the theft of funds but a form of “denial of service” for the entire industry, resulting in thousands of hours of remediation work, dependency verification, and secret rotation.¹³ The incident also created an urgent market for security solutions, which could be part of the threat economy.²⁵
B. The Shai-Hulud Worm: A New Era of Threat
The Shai-Hulud worm represents an escalation of the threat, relying on autonomy and automation. Its propagation mechanism is particularly ingenious and systemic.¹⁴ After compromising a maintainer’s account, the worm executes its malicious script during the package’s postinstall phase.¹⁴ This script searches for and steals authentication tokens for NPM and GitHub repositories, as well as access keys for cloud services like AWS and GCP.¹⁵ Once the credentials are stolen, the worm identifies the 20 most popular packages managed by the compromised maintainer.¹⁶ It then injects its own code into these packages, modifies them to execute its script, and publishes new corrupted versions to the NPM repository.¹⁴
The data exfiltration technique is also noteworthy. Rather than sending the stolen secrets to a central server controlled by the attacker, the worm publishes them in newly created public GitHub repositories forked from private ones, adding the suffix -migration.¹⁴ This method, which uses the victim’s own infrastructure to exfiltrate data, makes detection more complex. The Shai-Hulud worm also used open-source security tools, like trufflehog, to search for other secrets on the filesystem, highlighting the evolution of cybercriminals who integrate legitimate development tools into their attack chains.¹⁴
| Characteristic | debug/chalk Attack | Shai-Hulud Worm |
| Date | September 2025¹⁰ | September 2025¹⁶ |
| Initial Vector | Targeted phishing of maintainers¹¹ | Targeted phishing of maintainers¹⁶ |
| Primary Mechanism | Malicious code injection in popular packages¹⁰ | Self-replicating worm exploiting auth tokens¹⁴ |
| Primary Targets | End-users of browsers with crypto transactions¹⁰ | Package maintainers, dev systems, cloud infra¹⁵ |
| Payload Type | JavaScript script (browser)¹³ | JavaScript script (post-install)¹⁴ |
| Direct Financial Impact | Very low²⁵ | Undefined, high potential for secret theft¹⁵ |
| Main Impact | Industry-wide denial of service, productivity loss¹³ | Exponential proliferation, secret theft, cloud infra compromise¹⁵ |
Part III. Systemic Impact and Multidimensional Consequences
The attacks on NPM repositories have consequences that extend far beyond individual incidents. They highlight systemic vulnerabilities that threaten the entire digital economy.
A. Assessment of Direct and Indirect Economic Losses
Economic losses are not limited to the direct theft of funds. While the debug/chalk attack had a negligible direct financial impact, it generated massive indirect costs.²⁵ Companies had to dedicate thousands of man-hours to auditing their dependencies, re-verifying their build environments, and implementing remediation measures, which is tantamount to a “denial of service” for the industry.¹³ These costs also include reputational damage, loss of customer trust, and the risk of litigation.²⁶ Financial projections estimate that supply chain attacks will cost $138 billion annually by 2031, reflecting the scale of this threat at a macroeconomic level.⁶ The Shai-Hulud worm demonstrates an even greater potential for financial loss due to its ability to steal access keys to cloud services, paving the way for ransomware attacks, cryptomining, or large-scale data theft.¹⁵
B. Risks to Data and Application Security
The compromise of a maintainer’s account can turn a trusted developer into an attack vector. The theft of authentication tokens and API keys (NPM, GitHub, AWS, GCP) represents not just a data loss, but a backdoor into a company’s internal systems.⁸ These credentials can allow attackers to penetrate production environments, steal sensitive data stored in cloud storage buckets, deploy ransomware, or even delete entire environments.¹⁵ The impact is systemic: the vulnerability of a single developer whose packages are used by a company can lead to the infiltration of the entire organization.
C. The Cascade Effect on Transitive Dependencies
The dependency model of the NPM ecosystem, where a simple package can be a transitive dependency for thousands of projects, is the main source of the cascade effect.⁸ Automated CI/CD pipelines are particularly vulnerable, as they download and install the latest versions of packages without human intervention, which can propagate a corrupted version across hundreds of applications almost instantly.⁹ Developers may not be aware that the application they are building contains a malicious package because it was included via an indirect dependency.¹⁰
D. Reputational Damage and Loss of Trust in Open Source
The repetition of major incidents, where trusted packages are “poisoned,” erodes the credibility of the open-source ecosystem.⁸ This model, founded on collaboration, transparency, and reliability, is called into question when its foundation is corrupted. This loss of trust may prompt companies to turn to proprietary solutions or to implement security controls so drastic that they could slow down innovation and development, which runs counter to the very purpose of open source.
Part IV. Strategies for Fortifying the NPM Supply Chain
To counter these threats, a proactive, multi-layered approach is necessary, involving both developers and organizations.
A. Recommendations for Developers and Maintainers
- Implement Two-Factor Authentication (2FA): Enabling 2FA is the first line of defense against account takeovers.²⁰ However, maintainers must be aware that even 2FA is not foolproof against sophisticated phishing.⁹
- Audit and Lock Dependencies: It is imperative to use the npm audit command to identify vulnerabilities in your project’s dependencies and npm audit fix to apply patches.²⁸ Locking versions via the package-lock.json file is crucial to ensure that installed packages are exactly those that have been audited and approved, thus preventing malicious substitutions by packages with higher version numbers.²²
- Limit Privileges and Monitor Secrets: Developers must ensure that secrets (API keys, passwords) are never published to the NPM registry.²⁷ It is recommended to use the –ignore-scripts flag when installing packages to reduce the risk of malicious code execution via lifecycle scripts.²⁷
B. Organizational Security Measures
- Integrate Security into the Development Lifecycle (CI/CD): Security must be integrated from the very beginning of the development process. Using Software Composition Analysis (SCA) and Static Application Security Testing (SAST) tools in build pipelines helps detect vulnerabilities before code is deployed.³² Securing ephemeral build environments is also essential to prevent the theft of secrets.³²
- Adopt Trusted Registries and Repositories: Using private NPM registries (e.g., instances of Nexus or Artifactory) acts as a “dependency firewall.”²⁷ These registries allow organizations to control and audit the packages that enter their ecosystem, ensuring they are safe before being used by developers. Using scopes for internal packages is another effective preventive measure against dependency confusion.²²
- Train Teams and Establish Response Protocols: Raising awareness about social engineering threats and training on how to recognize phishing emails are crucial human measures.³ Companies must also establish incident response plans to react quickly in the event of an attack, including identifying compromised packages, revoking exposed secrets, and communicating with stakeholders.³⁴
| Threat/Vulnerability | Prevention Measure | Tools/Commands |
| Account Compromise | Enable Two-Factor Authentication (2FA) for publishing accounts. | npm profile enable-2fa²⁷ |
| Dependency Vulnerabilities | Regular auditing and version locking in the dependency file. | npm audit, npm audit fix, package-lock.json²⁸ |
| Typosquatting / Dependency Confusion | Use private registries and scopes for internal packages. | Private NPM registries, @your-org/package³³ |
| Execution of Malicious Scripts | Install packages with lifecycle script execution disabled. | npm install –ignore-scripts²⁷ |
| Publication of Secrets | Configure project files to exclude sensitive data. | .npmignore, files property in package.json, npm publish –dry-run²⁷ |
Conclusion: Towards Collective Resilience
The attacks on NPM repositories in 2025 are not anomalies but clear illustrations of an ever-evolving supply chain threat, characterized by professionalization, diversified vectors, and increased sophistication. They demonstrate that the simple trust model of the open-source ecosystem is no longer sufficient. The human factor, transitive dependencies, and configuration flaws are the entry points that cybercriminals exploit to turn a targeted attack into a systemic threat.
The collective resilience of the ecosystem depends on a shared responsibility. Maintainers must fortify their accounts and processes. Developers must adopt a “zero trust” posture by auditing and locking their dependencies. Companies, in turn, must integrate security into the core of their development processes and CI/CD infrastructure. The security of the software supply chain is a complex challenge, but the answer lies in a combination of robust technical measures, continuous vigilance, and a shared awareness of the threat.
