The npm registry can’t protect you: The new JavaScript supply chain attacks

As of December 2025, malware is spreading through the npm registry, turning trusted dependencies into infected attack vectors. The Shai-Hulud attack, named after the sandworms from Dune by its creators, doesn't wait for developers to make mistakes. It executes automatically during package installation, steals credentials from developer machines and CI/CD pipelines, then uses those credentials to infect every other package its victims maintain. The worm is replicating itself across the ecosystem faster than security teams can respond and holding developers’ machines hostage.

npm attacks are a growing class of threats, with the latest wave of the Shai-Hulud campaign being the latest escalation. These supply chain attacks are fueled by automation that favors attackers, AI-generated malware flooding the public registries, and continuous deployment pipelines that turn every update into a potential security risk. JavaScript is one of the most popular programming languages, powering everything from healthcare systems to financial services, so when a dependency is compromised, damage spreads quickly.

This article walks through what npm supply chain attacks are, how attacks in 2025 worked, why they're getting worse, what the business impact looks like, and how to prevent them.

What is an npm supply chain attack?

In an npm supply chain attack, an attacker compromises a trusted package in the npm registry and uses it to distribute malicious code to users who install or update that package.

Rather than attacking your application directly, attackers move "upstream" into packages your team already trusts. They typically gain access through maintainer account takeover, credential theft, or by publishing malicious versions of legitimate packages. Once compromised code lands in the registry, it spreads like rats scampering from ship to shore. It’s automatically installed via normal development workflows into every environment that trusts the package.

npm supply chain attacks exploit trust and process rather than technical vulnerabilities. When developers run npm install, they're implicitly trusting that the package registry, the maintainer, and the entire build-and-release pipeline are secure. Attackers build credibility as contributors before injecting malware by stealing maintainer credentials through phishing, or avoid scrutiny by publishing malicious updates that look like routine maintenance.

The real danger is that malicious code executes automatically during the installation process. Lifecycle scripts run without confirmation, transitive dependencies get pulled in without review, and automated CI/CD pipelines promote compromised packages straight into production. By the time teams discover the compromise, malware has already spread across the developer environments and build systems.

Recent npm supply chain attacks you should know about

Over the last couple of years, we’ve seen some major, novel attacks targeting npm in particular. There’s no one formula that outlines npm supply chain attacks, but all npm supply chain attacks exploit the same fundamental weakness: developers trust that packages in the registry are safe to install, and that trust is routinely violated. We’ll look at a few of the big ones here.

Shai-Hulud malware and campaign-style npm attacks

As of December 2025, the latest version of Shai-Hulud remains an active threat. Organizations are still discovering compromised packages in their environments, and the campaign shows no signs of stopping. The Shai-Hulud campaign represents a whole new class of persistent, sophisticated, multi-wave supply chain attacks, treating open-source ecosystems as long-term ongoing targets rather than one-time opportunities.

The Shai-Hulud campaign had been active in previous waves throughout 2024, but it exploded into a major threat in September 2025 when researchers identified over 500 compromised npm packages stealing developer credentials. CISA issued an emergency alert on September 23, 2025, warning organizations about the self-replicating worm behavior that allowed the malware to spread automatically by stealing credentials and using them to infect other packages.

The situation escalated last month with a second wave called Shai-Hulud 2.0. They spread beyond the npm ecosystem into Maven Central, the primary Java package registry, and the scale exploded far beyond what the attackers had attempted before; the second wave compromised over 28,000 GitHub repositories and exposed more than 11,000 secrets, including API keys, database credentials, and authentication tokens.

The most alarming part is that the attack became self-replicating. When a developer installed a compromised package, the malware stole their npm tokens and GitHub credentials. It then used those npm tokens to automatically identify every other package that the developer maintained, inject malicious code into each one, and publish new compromised versions to the registry.

At the same time, it used the stolen GitHub credentials to commit malicious code directly to repositories the developer had access to. The malware spread exponentially without requiring any additional human intervention from the attackers. Just one compromised developer could automatically lead to dozens of compromised packages, which infected dozens more developers, whose packages infected hundreds more.

It also added a destructive "dead-man's switch" that monitors the malware's access to GitHub and npm. If defenders try to delete malicious repositories and revoke tokens to stop the spread, the malware retaliates by attempting to destroy all files in the infected user's home directory, using overwrite methods that make data recovery nearly impossible. This creates a hostage situation where coordinated takedowns risk triggering mass data destruction across thousands of infected developer machines and build servers.

Shai-Hulud changed how the community thinks about npm supply chain security. It proved that:

• Worm-like self-replication is possible in package ecosystems

• Attacks can sustain multi-wave campaigns

• The dead-man’s switch can create hostage scenarios

Debug and chalk ecosystem compromise

In July 2024, attackers executed one of the most significant npm supply chain attacks on record by compromising the debug and chalk packages, two widely used libraries with over 2 billion combined weekly downloads. The attack began with a sophisticated phishing campaign. Attackers registered the domain “npmjs.help” three days before launching the operation and sent emails from "support@npmjs.help" to maintainers of high-value packages, impersonating official npm support. The emails convinced maintainers to enter their credentials on a fake login page, giving attackers full publishing rights to their accounts.

Once inside, attackers published malicious versions of debug, chalk, and 16 related packages. The malware targeted Web3 applications, hooking into browser-based wallet providers like MetaMask and Trust Wallet to intercept and modify transactions in real-time, before they were signed and submitted to the blockchain.

The attack was subtle and sneaky. Instead of just replacing wallet addresses with the obvious attacker-owned addresses, the malware used fuzzy string matching algorithms to generate addresses that looked visually similar to the legitimate destination addresses. For example, if a user were sending funds to an address starting with "0x1a2b3c...", the malware would replace it with an attacker-controlled address, such as "0x1a2b3d..." (see the difference?). This made it harder for users to notice the substitution during the brief moment they reviewed transaction details.

The malware exploited multiple blockchain networks, including Ethereum, Bitcoin, Solana, and TRON. It granted unlimited spending permissions to attacker wallets, so the attackers could drain funds from the victim's entire wallet balance over time.

PhantomRaven npm malware

The PhantomRaven campaign, discovered in October 2024, exploited a systemic design flaw in npm's dependency management system. Instead of including malicious code directly in packages, attackers hid malicious dependencies behind invisible HTTP URL links. When developers installed these packages, npm automatically fetched malware from attacker-controlled servers without any indication that external code was being pulled. Security scanners analyzing the packages saw "0 Dependencies" because they only checked what was published in the registry, not what would be dynamically fetched during installation.

The campaign contaminated 126 packages with over 86,000 combined installs and demonstrated how npm's flexibility can be weaponized against developers. PhantomRaven also pioneered the exploitation of AI hallucinations through slopsquatting, publishing malicious packages with names that AI assistants had invented (more on this later).

Developers who trusted the AI suggestions inadvertently installed malware that had been hallucinated into existence by the AI. npm eventually removed the packages, but the underlying vulnerability remains unfixed, meaning similar attacks will continue exploiting the same technique.

Why npm supply chain attacks are getting worse

If it looks like npm supply chain attacks are becoming more frequent and destructive, that’s because they are. Attackers are scaling up by taking advantage of AI and the popularity of JavaScript. Let’s look more at some of these causes in detail.

Automation has shifted the economics in favor of attackers

In 2024, Sonatype identified over 500,000 malicious npm packages, representing 98.5% of all malicious packages found across language ecosystems that year. At this volume, we can safely assume that hackers aren’t writing these by hand. They’re using AI and scripts.

AI is fueling slopsquatting and mass malware generation

AI coding assistants have created new entry points for hackers; slopsquatting, which we saw in PhantomRaven, is a perfect example. When developers ask ChatGPT or GitHub Copilot for package recommendations, these tools sometimes hallucinate plausible-sounding package names that don't actually exist in the npm registry. Attackers monitor these AI-generated suggestions, register the non-existent package names, and publish malicious code under those names. When developers follow the AI's recommendation and run npm install, they're installing malware that was created specifically because an AI invented the package name.

The JavaScript ecosystem's scale and churn drive dependency challenges

npm hosts nearly 3.5 million packages, twice the combined size of Maven Central and PyPI. The registry processes billions of downloads per week. Developers constantly publish new versions, each of which could serve as a new entry point for an attacker. A typical application might directly depend on 50 packages but transitively depend on something like 500. Developers can't realistically audit every transitive dependency, so the malware can sneak in through these layers.

Continuous deployment has turned every update into a potential infection event

In addition to volume, frequency makes thorough scrutiny impossible. Organizations shipping multiple times per day can't manually review every dependency change, so they rely on automation, trust, and post-deployment monitoring. Attackers take advantage of that trust by publishing malicious updates that look like routine releases. Security scanners analyzing packages after installation may eventually detect malware, but by then, the compromised code has already executed and begun wreaking irreparable damage.

The business impact of npm supply chain attacks

Security, compliance, and audit exposure

Depending on your industry and location, you’re subject to several different regulations. Financial services firms that handle payment card data, for example, must comply with the PCI-DSS. A supply chain attack that introduces malware violates those requirements, and failing an audit can result in loss of payment processing privileges and fines.

Similarly, healthcare organizations subject to HIPAA face similar exposure when malicious code exfiltrates data or creates unauthorized access points. And if you’re a government contractor seeking FedRAMP authorization, your approval could be delayed by months or years after just one documented supply chain compromise. Those with existing authorization risk having their Authority to Operate (ATO) suspended or revoked.

Operational risk, downtime, and incident response costs

Supply chain attacks like the Shai-Hulud force organizations to audit tens of thousands of repositories for compromised credentials. Emergency patching creates cascading problems. It’s not as simple as just deleting the malware. Teams have to rotate API keys, revoke access tokens, rebuild container images, and redeploy services.

When a team removes a compromised package, they are likely to find that multiple services depend on it. Replacing the package requires checking for compatibility, refactoring code to work with the new package, and coordinating deployments across a network of related and interconnected services.

Teams often find themselves in a situation where they must choose between quick fixes that might disrupt production or continued exposure to viruses. The more risk-averse teams shut down their affected systems entirely until they have completely analyzed and removed the issues, creating downtime for customers.

Long-term trust, customer risk, and brand damage

When a supply chain attack hits your organization, customers begin to ask tough questions about your security practices. Prospects choose competitors who haven't made headlines for the wrong reasons. The damage hits hardest for companies selling security or infrastructure, whose entire value proposition depends on trust and reliability. Brand damage extends beyond the immediate revenue loss through negative press coverage and slower sales cycles.

How to prevent npm supply chain attacks

npm supply chain attacks are pretty scary, but you can take steps to prevent them. The best way to prevent malicious packages from stealing your data or corrupting your systems is to make sure they never reach your infrastructure in the first place.

Replace blind registry trust with verified sources

Packages built from source code avoid entire classes of attacks. If an attacker compromises a maintainer account and publishes a malicious tarball, the published artifact won't match the source code in the repository. Chainguard Libraries for JavaScript continuously builds npm packages from source in SLSA Level 2 build infrastructure, preventing approximately 99.7% of known malicious npm packages because most either lack valid source attribution or publish artifacts that don't match their claimed source.

Secure JavaScript libraries as the first line of defense

Pre-verified libraries eliminate the window between package publication and detection. Instead of consuming packages directly from the public npm registry and scanning them after installation, teams can use packages that were already verified and built from trusted sources. Chainguard Libraries for JavaScript rebuilds popular packages from source and delivers them through malware-resistant registries with built-in Software Bill of Materials (SBOMs) documentation and cryptographic signing.

Provenance, signing, and build integrity by default

Provenance metadata describes where software came from and how it was built. When combined with cryptographic signing, organizations get tamper-evident seals that fail verification if someone modifies a package after it was built. Teams can enforce policies that only allow signed packages with valid provenance into their systems, blocking packages that lack verifiable origins. Chainguard uses Sigstore to sign all packages built in their systems, giving you mathematical proof of build integrity that's publicly verifiable.

Reduce dependency sprawl to shrink the attack surface

Every dependency is a potential entry point for an attack. Think about whether each new package is actually necessary versus when it makes sense to build the functionality in-house. Minimizing dependencies also reduces your maintenance overheads (fewer security updates) and makes audits simpler if you unfortunately find out that your supply chain has been compromised.

Harden production with minimal, secure runtime images

Production environments should contain only what you need to run the application (and nothing else). Minimal container images reduce attack surface by removing unnecessary packages, system utilities, and development tools. Chainguard Containers provide minimal images that are continuously rebuilt with zero known CVEs at build time and automatically patched when new vulnerabilities are discovered.

Eliminate npm supply chain risk at the source

To achieve the best possible security, you have to prevent compromised software from entering your supply chain rather than detecting it after the fact. Chainguard addresses risk at the source, so your systems can stay secure between releases. With Chainguard, you’re getting:

• Secure JavaScript libraries built from verified source code eliminate the risk of malicious packages published to the npm registry, preventing approximately 99.7% of known malicious packages from reaching your systems.

• Cryptographic signing and software provenance attestations that provide verifiable proof of build integrity with machine-readable SBOM documentation.

• Continuously rebuilt, minimal runtime images ensure production environments stay hardened, with automatic patching within 7 days for critical vulnerabilities.

• Automated vulnerability remediation at the source, which reduces emergency patching cycles and prevents alert fatigue.

• Compatibility with existing developer workflows, so teams can adopt preventive security without slowing down their delivery.

Ready to improve your security? Connect with an expert to discover how Chainguard can help mitigate npm supply chain risk for your organization.