Breakdown: Widespread npm Supply Chain Attack Puts Billions of Weekly Downl...

On September 8, 2025, the JavaScript ecosystem faced a major supply chain attack targeting 18 widely used npm packages. These packages alone see over 2.6 billion downloads each week, making this one of the most significant npm attacks in recent memory. The incident highlights the growing risk of supply chain threats in cloud-native development environments and underscores why prevention-first security is more important than ever.

In the open-source software supply chain, the rapid proliferation of malicious code across trusted dependencies poses significant risks to developers and organizations relying on these packages. As the attack unfolded, the community and security vendors mobilized swiftly to mitigate its impact, but the event serves as a stark reminder of the persistent threats facing the software development ecosystem.

The Attack

The attack was initiated through a targeted phishing campaign against a package maintainer known as "qix." The attackers impersonated npm support, claiming that the maintainer's two-factor authentication credentials needed to be updated. By following the instructions, the maintainer inadvertently provided the attackers with access to their account.

Using this access, the attackers published malicious updates to 18 npm packages, including widely used libraries such as debug, chalk and ansi-styles. These malicious versions were live for roughly two hours before being detected and removed. In that short window, the attack had the potential to impact millions of developers and cloud environments that rely on these widely used libraries.

The malicious code was a "crypto-stealer" or "wallet-drainer" designed to be executed in users' web browsers and steal $$$ exchanged in cryptocurrency transactions.

Affected Packages

• [email protected]
• [email protected]
• [email protected]
• [email protected]
• [email protected]
• [email protected]
• [email protected]
• [email protected]
• [email protected]
• [email protected]
• [email protected]
• [email protected]
• [email protected]
• [email protected]
• [email protected]
• [email protected]
• [email protected]
• [email protected]

How the Malware Operates

The malicious code injected into the compromised npm packages was specifically designed to target cryptocurrency wallets, but its sophistication highlights a broader threat to development pipelines and cloud environments. Its operation can be broken down into several stages:

1. Injection into the Browser: The malware integrates itself directly into the browser environment, hooking critical functions such as fetch, XMLHttpRequest and wallet-specific APIs like window.ethereum and Solana APIs, which allows it to intercept web traffic and wallet interactions in real time.
2. Monitoring for Sensitive Data: Once active, the code scans network responses and transaction payloads for cryptocurrency wallet addresses and transaction details. It can recognize multiple formats across Ethereum, Bitcoin, Solana, Tron, Litecoin and Bitcoin Cash.
3. Rewriting Transaction Targets: When a wallet or transaction is identified, the malware replaces the legitimate destination address with one controlled by the attacker. It often uses "lookalike" addresses via string-matching to make substitutions less obvious, increasing the likelihood of successful theft.
4. Hijacking Transactions Before Signing: The malware modifies transaction parameters before the user signs them. For Ethereum and Solana, this can include altering recipients, approvals or allowances. Even if the user interface appears correct, the signed transaction routes funds to the attacker.
5. Maintaining Stealth: The malware minimizes its footprint to evade detection by conventional security tools. If a crypto wallet is detected, it avoids obvious swaps in the UI, remaining silent in the background to capture and alter real transactions without alerting the user.

While the immediate objective of this attack was financial theft, the method demonstrates the broader threat that any compromised library, even one not directly handling cryptocurrency, can serve as a vector for malicious activity. Such activity could include the manipulation of data, unauthorized network access or exfiltration of sensitive information within development pipelines and cloud workloads.

The Impact and Response

The malicious versions were live on the npm registry for approximately 2 hours. During this window, any developer or automated build system that installed or updated these packages could have downloaded the compromised code.

The open-source community and security firms responded quickly:

1. Community Detection: Developers noticed suspicious activity and raised alerts on GitHub and other platforms.
2. Maintainer Action: Once alerted, the original maintainer confirmed the account compromise and immediately started working with npm to revert the changes.
3. npm Security Team: npm's security team removed the malicious package versions from the registry and secured the compromised account.

How to Check If Your Organization Is Effected

For Cortex Cloud™ customers, the platform provides a detailed inventory of your used npm packages, which you can find in the Code Asset SoftwarePackages inventory section.

Once on that page, you can search for any of the affected packages and find whether they are used in any of your applications and where exactly.

How Security Teams Should Respond

If the affected packages are found within your environment, teams should install the latest version of the relevant npm packages (or any package that you deem safe). In the application build process, they should make sure they pin the npm install command to the new and secured npm package version.

Anatomy of a Software Supply Chain Attack

​​The attackers didn't target the final product (an individual's application). They've targeted a trusted component within the product's "supply chain."

Think of it like building a car. Instead of trying to cut the brakes on every single car after it's sold, a supply chain attacker would compromise the factory that manufactures the brake pads. By injecting a defect at the source, every single car built using those faulty pads is now compromised.

The supply chain is the sequence of steps and components used to build an application.

• The Component Supplier: The package maintainer (qix) and the npm registry are the trusted suppliers.
• The Component Part: The npm packages like chalk and debug are the components-the "brake pads."
• The Manufacturer: Developers are the manufacturers, who select these trusted components to build their applications.
• The Final Product: The finished software, websites and servers that developers create.

The attackers didn't hack thousands of individual websites. They went "upstream" and compromised a single, trusted source-the maintainer's account. By poisoning the packages at the source, the malicious code was automatically distributed downstream to every developer, build server, and application that installed or updated those packages.

The method is so effective and dangerous because it exploits the inherent trust that developers place in the open-source ecosystem. A single breach can have a massive, cascading impact, compromising countless systems that rely on that single piece of code.

Preventing Supply Chain Attacks with Cortex Cloud

Cortex Cloud's Software Supply Chain Security (SSCS) solution can detect the use of malicious dependency packages before an application is built, during the build process, and even at runtime. This capability is powered by our SBOM functionality, which provides deep visibility into every component of an application. With this, customers can proactively block unsafe builds or remove compromised applications already running in production.

Using SBOM technology, Cortex Cloud identifies both direct and transitive dependency packages with known CVEs and prevents their use. For packages without published CVEs, our proprietary Operational Risk model provides additional protection. The model evaluates open-source packages based on factors such as maintainer activity, deprecation status and community adoption, allowing us to identify risky components even in the absence of known vulnerabilities.

In the case of the malicious npm packages used in this attack, the sudden release of new versions would have been flagged as highly suspicious by our Operational Risk model. Combined with other operational indicators, this would have prevented the compromised packages from being introduced into customer applications in the first place.

Out-of-the-Box CI/CD Rules Mapped to Industry Standards

Palo Alto Networks customers can leverage the following Cortex Cloud out-of-the-box (OOTB) CI/CD rules, along with our remediation recommendations, to prevent attacks similar to the recent "npm Debug" incident. Each rule is mapped to industry standards, including the CIS Software Supply Chain Security Guide and the OWASP Top 10 CI/CD Risks. Customers who regularly run compliance tests should ensure these policies are enabled to provide effective protection against supply chain threats.

• Packages insecurely installed through "npm install" command

In common package.json configurations, the "npm install" command updates and installs package versions. "npm install" doesn't check for package integrity, allowing attackers who have gained control of a dependency package to upload a malicious version, which is then downloaded and installed automatically when running "npm install".

• Repository missing npm lock file

The package-lock.json file includes information about the dependencies of a package, as well as the hashes of the downloaded packages and the source URLs, which can be used to verify the integrity of the package installation. If a package-lock.json file is not used when running "npm ci" during the package build process, the packages will be installed without undergoing integrity checks provided by the package-lock.json file. This may lead to the package being tampered, which could potentially result in malicious code being executed in the pipeline or delivered to production.

• npm package lock file verifies integrity with weak hash algorithm

Old versions of package-lock.json files using SHA-1 to verify the integrity of downloaded dependencies are vulnerable to collision attacks in which two inputs can produce the same output, meaning that attackers can create a malicious package with the same hash of a legitimate package, bypassing the integrity validation. An attacker who has gained access to a maintainer account could trick a pipeline that uses "npm ci" to install a package and verify the dependencies integrity by replacing a legitimate package with a malicious version that has the same hash, inadvertently introducing malicious code that could potentially reach production.

Note: Due to SHA-1 vulnerabilities, it was deprecated by NIST in 2011.

• npm project contains unused dependencies

npm dependencies can potentially execute code during installation. Each added dependency expands the attack surface. Unused dependencies elevate the risk, as they unnecessarily widen the attack surface of a project without valid justification. An unused and compromised dependency exposes the project to unnecessary risks, potentially allowing malicious code to run on developers' endpoints, during build, or in production.

• npm package downloaded from git without commit hash reference

npm packages can be installed using a URL of a git repository, which may contain a reference to a branch, tag or commit hash. Without using a commit hash reference, the integrity of the downloaded package can't be guaranteed. Potential results could involve developers or build servers downloading a different version of the package than intended,and one containing malicious code could expose both the development and production environments to risks.

To learn more about Cortex Cloud, schedule a demo with an expert.