Supply chain attacks sit at the uncomfortable intersection of trust and exploitation. They occur when attackers infiltrate the systems of a trusted vendor or maintainer and use that access to inject malicious code or hardware that compromises all of the vendor’s downstream customers. This tactic is particularly dangerous in open‑source ecosystems such as Node Package Manager (npm), where millions of developers reuse components without vetting each maintainer. In recent years the npm community has faced several supply‑chain compromises, culminating in dramatic campaigns during September 2025 that illustrate just how fragile software supply chains have become.
What is Node Package Manger?
Node Package Manager (npm) is the world’s largest software registry, used by developers to share and download open-source packages (libraries or modules) for Node.js applications. It’s what allows developers to quickly build web apps, APIs, and backend systems by reusing pre-built code rather than writing everything from scratch. The registry hosts over 2 million packages, downloaded billions of times weekly. These packages are often interdependent; one module might rely on dozens or even hundreds of others.
What Is a Software Supply Chain Attack?
A software supply chain attack occurs when a threat actor compromises a trusted component or service used in software development, then pushes malicious updates or code to all downstream users. CrowdStrike notes that threat actors may hijack update servers, compromise CI/CD infrastructure, register fake packages with higher version numbers (dependency confusion), steal code‑signing certificates or infect widely used open‑source modules. Because modern software relies on hundreds of third‑party libraries, a successful compromise of a single module can ripple through thousands of applications. The consequences are severe: Target’s 2013 breach stemmed from an HVAC contractor, SolarWinds’ Orion platform was compromised in 2020, and hardware manufacturers have distributed malware via factory firmware. The attackers exploit trust in the supplier to bypass traditional defenses, making early detection and prevention critical.
Brief History of npm Supply Chain Incidents
The npm ecosystem’s openness has enabled innovation but also made it a lucrative target. In November 2018, the event‑stream package, used by the Copay cryptocurrency wallet, was hijacked by a new maintainer who added a malicious dependency (flatmap‑stream). The inserted code decrypted and executed malware designed to harvest account details and private keys from Copay users with large balances. Npm removed the malicious version after discovery, but the incident highlighted how social engineering and unvetted maintainers can introduce malicious code.
In October 2021, the popular ua‑parser‑js library was hijacked. Malicious versions (0.7.29, 0.8.0 and 1.0.0) were published for roughly four hours; they installed malware that could run on developers’ machines, CI/CD servers and production environments, potentially stealing credentials and secrets. The method used to obtain the publisher’s credentials is unknown, but the episode prompted calls for freezing dependencies and monitoring vulnerability feeds.
A few weeks later, attackers compromised the coa and rc packages by hijacking the maintainers’ npm accounts. The malicious versions executed a pre‑install script that used Windows certutil to download and run a trojan capable of stealing browser passwords and credit card data. These packages had millions of downloads, and their hijacking underscored the need for two‑factor authentication and proactive monitoring.
Smaller incidents continued in subsequent years, but the early events underscored a pattern: attackers leverage phishing and social engineering to gain credentials from maintainers, then use npm’s trust relationships to propagate malware widely.
The September 8 2025 Wallet‑Drainer Campaign
The most widespread npm compromise to date occurred on September 8 2025. According to JFrog’s analysis, a malicious actor compromised the npm registry by publishing trojanized versions of 18 widely used packages, including debug, chalk, ansi‑styles, simple‑swizzle and strip‑ansi. The attacker obtained developers’ tokens through a phishing campaign and then uploaded the malicious releases. Massively popular packages such as debug had over half a million downloads of the compromised version, and the combined download count of the infected releases exceeded 2.5 million.
The payload was a cryptocurrency stealer. The injected code obfuscated with the javascript‑obfuscator library hooked JavaScript’s XMLHttpRequest.send method to monitor web3 traffic. When a supported cryptocurrency transaction was detected, the malware intercepted the request and replaced the recipient’s address with an attacker‑controlled address, redirecting the funds. JFrog’s blockchain analysis suggests that the poorly obfuscated malware was detected quickly; the attackers stole roughly US $500 before the packages were removed. Still, the attack demonstrated how an adversary can embed a wallet drainer into widely trusted modules and propagate it to millions of systems.
Despite the short exposure window, the campaign exposed deep structural weaknesses. The affected packages were trivial utilities maintained by a handful of developers, yet they underpin huge portions of the JavaScript ecosystem. JFrog notes that half of the codebase of modern applications depends on single‑line utilities maintained by a single developer. After the initial set of packages was removed, the attacker uploaded additional compromised versions of packages associated with DuckDB, which were quickly taken down. The incident underscores the fragility of the ecosystem and the need for maintainers and users to adopt stronger security practices.
The Shai‑Hulud Worm – September 23 2025
Two weeks later, a far more sophisticated attack surfaced. Palo Alto Networks’ Unit 42 dubbed it “Shai‑Hulud,” a self‑replicating worm that compromised more than 500 npm packages. Investigators believe the initial access vector was a phishing campaign that spoofed npm support to convince developers to update multi‑factor authentication. Once a developer’s credentials were harvested, the malicious package executed a multi‑stage post‑installation script that scanned for .npmrc files, GitHub personal access tokens (PATs) and cloud service API keys (AWS, GCP and Azure). The worm uploaded harvested secrets to an attacker‑controlled GitHub repository named “Shai‑Hulud” and used the stolen tokens to authenticate to npm and publish trojanized versions of the victim’s packages.
Unlike the wallet‑drainer, Shai‑Hulud’s goal appears to be credential harvesting and lateral propagation. The malware cloned private repositories, injected malicious GitHub workflows, persisted across updates and automatically created new branches that exfiltrated secrets. Trend Micro notes that it used tools like TruffleHog to scan entire development environments for secrets and pivoted to compromise additional packages, making it self‑propagating and autonomous. The campaign underscores how attackers are combining automation and artificial intelligence; Unit 42 suspects an LLM was used to generate portions of the Bash script, enabling rapid adaptation.
Security researchers have not reported widespread exploitation of the worm. Trend Micro observed the malware in only a few environments and noted that some payload variants were cryptojackers. Nevertheless, the ability of Shai‑Hulud to embed itself in development environments and propagate without human intervention is a troubling harbinger for future attacks.
Lessons and How to Protect Yourself
These incidents offer important lessons for organizations, developers and security teams.
- Apply strict access controls and multi‑factor authentication (MFA). Attackers repeatedly succeeded by phishing maintainers for passwords or tokens. Enforcing phishing‑resistant MFA on developer accounts and registries, using hardware keys where possible, dramatically reduces the chances of credential compromise. Periodically rotate all secrets and revoke unused tokens.
- Review and pin dependencies. Npm allows package maintainers to modify or unpublish releases, which can lead to unanticipated updates. Organizations should maintain a software bill of materials (SBOM) and “pin” dependencies to specific versions, then audit them for integrity. CISA recommends maintaining an inventory of software licenses and understanding how each component is supportedcisa.gov. Avoid automatically installing new minor versions without verification.
- Monitor for malicious post‑install scripts. Both the wallet‑drainer and Shai‑Hulud attacks abused npm’s ability to run post‑installation scripts. Use package managers with script‑execution restrictions, or inspect packages for suspicious scripts before installation.
- Audit and secure CI/CD and version‑control systems. Shai‑Hulud exploited GitHub PATs and injected malicious workflows. Configure least‑privilege permissions for CI/CD tokens, disable token reuse across projects and monitor for unusual repository creation or commit activity (e.g., unknown “Shai‑Hulud” repository names). Rotate secrets stored in repositories and prohibit the use of long‑lived personal access tokens.
- Educate developers about phishing. Provide ongoing training to help developers recognize and report phishing attempts. The September 8 attack began when maintainers received fake npm support emails prompting them to update 2FA; verifying email headers and cross‑checking with official communications would have prevented the compromise.
- Integrate supply chain risk management into business processes. CISA advises organizations to establish formal cyber supply‑chain risk management programs, maintain inventories of software components and collaborate with suppliers to ensure secure development practices. Use third‑party assessments and require suppliers to provide SBOMs and vulnerability disclosure policies.
Conclusion
The September 2025 npm attacks show that the software supply chain is under sustained pressure from increasingly sophisticated adversaries. From single‑maintainer utilities to large cloud modules, any component can become a vector for malware or credential theft. By understanding past incidents, implementing robust authentication, auditing dependencies and integrating supply‑chain risk management, organizations can reduce the likelihood that a compromised package will become their undoing. As the open‑source community continues to innovate, security must remain a shared responsibility – because a single compromised package can still threaten the entire ecosystem.