NPM supply chain attack: A phishing scam compromised packages with over 2 billion weekly downloads

The phishing scheme and account compromise

The supply chain attack was initiated by a meticulously crafted phishing email sent to Josh Junon, a prolific and trusted npm maintainer known as Qix. The email, which came from the deceptive domain support[at]npmjs[dot]help—a lookalike of the legitimate npmjs.com—was part of a scare tactic. It falsely claimed that Junon's account would be locked on September 10, 2025, if he did not update his Two-Factor Authentication (2FA) credentials, which the email stated were over 12 months old.

(Image taken from GitHub.)

The phishing site featured a login form that, upon submission, would exfiltrate the user's credentials to an attacker-controlled URL. Despite his usual caution, Junon, who was on his mobile device and having a long, busy week, mistakenly clicked the link and entered his credentials. This single action granted the attackers full control of his npm account, allowing them to publish malicious versions of the packages he maintained. The attackers registered the phishing domain just three days before the attack, demonstrating a calculated and prepared assault.

A wide-reaching and stealthy attack

The compromise was first detected by Aikido Security on September 8 at 13:16 UTC. Their intelligence feed flagged a series of suspicious package updates from Junon’s account. Upon confirming the compromise, Aikido notified Junon via Bluesky (who was already aware of the situation), and he began the cleanup process just over an hour and a half later, at 15:15 UTC. The rapid response from both the security researchers and the maintainer helped mitigate the potential damage.

The attackers leveraged their access to inject malicious code into the latest versions of 18 highly popular npm packages. The combined weekly download count of these packages is around 2.6 billion, making this a truly massive attack.

The most downloaded compromised packages included (the number of weekly downloads is shown in parentheses):

• ansi-styles (371.4 million)

• debug (357.6 million)

• chalk (300.0 million)

• supports-color (287.1 million)

• strip-ansi (261.2 million)

• ansi-regex (243.6 million)

• wrap-ansi (198.0 million)

• color-convert (193.5 million)

• color-name (191.7 million)

• is-arrayish (73.8 million)

• slice-ansi (59.8 million)

• error-ex (47.2 million)

• color-string (27.5 million)

• simple-swizzle (26.3 million)

• supports-hyperlinks (19.2 million)

• has-ansi (12.1 million)

• chalk-template (3.9 million)

• backslash (0.26 million)

Many of these are foundational dependencies, co-maintained with Sindre Sorhus, one of the most popular maintainers on npm. This deep integration within the JavaScript ecosystem magnified the "blast radius" of the attack. By compromising one high-profile account, the attackers were able to reach a vast number of applications and libraries indirectly dependent on these packages.

How the malware operated

The malicious code, which seems to be consistent across all compromised packages, was designed to act as a browser-based interceptor, targeting cryptocurrency and Web3 activity. It was highly intrusive and stealthy, operating at multiple layers to evade detection.

The malware's core functionality involved a multi-step process:

1. Injection and hooking: The code injected itself into the browser's core JavaScript functions, such as fetch and XMLHttpRequest, and common wallet APIs, specifically the window.ethereum object for Ethereum-compatible wallets like MetaMask, as well as the APIs used by Solana-compatible wallets like Phantom. This allowed it to intercept both web traffic and wallet activity.

2. Data surveillance: It scanned network responses and transaction payloads for anything that resembled a cryptocurrency address or transfer. The malware was capable of recognizing multiple formats across major chains, including Ethereum, Bitcoin, Litecoin, Solana, and Tron.

3. Address replacement: Using string-matching logic and pre-defined lists of attacker-controlled addresses, the malware would replace the legitimate recipient's address with a "lookalike" address from the attacker's list. This made the fraudulent transaction harder to spot.

4. Transaction hijacking: Before a user could sign a transaction, the malware would alter the transaction parameters (e.g., recipients, approvals, allowances). Even if the user's interface showed the correct destination, the underlying transaction data was already modified to route funds to the attacker.

5. Stealth and deception: The code was heavily obfuscated to hide its intent. It used variables with _0x prefixes and a massive array of obfuscated strings that were decoded at runtime. To avoid raising suspicion, it would sometimes avoid obvious changes in the UI while silently hijacking the transaction in the background. The malware would even return a fake "success" response to the application, making it appear as if the transaction went through as intended.

The malicious code specifically targeted cryptocurrency-related interactions, meaning that not all applications using the compromised packages were affected. According to Andrew MacPherson, Principal Security Engineer at Privy, specific criteria had to be met for an application to be vulnerable, including a fresh install or a package-lock.json file created during the brief window when the malicious versions were active.

Broader implications and developer recommendations

The Qix attack is a stark reminder of the growing threat of supply chain attacks. As demonstrated by recent incidents targeting eslint-config-prettier and other npm libraries, attackers are increasingly focusing on the software supply chain to gain a foothold in thousands of applications simultaneously. The web browser, with its extensive API surface, has become a primary target for these types of attacks.

For now, developers are strongly advised to take the following steps to protect themselves and their users:

• Roll back: Immediately roll back to a known safe version of any compromised package. The malicious versions have been removed by the npm team, but it is crucial to ensure your projects are using secure, previously vetted releases.

• Audit dependencies: Conduct a thorough audit of your package.json and package-lock.json files to check for any recent updates to the affected packages that may have occurred during the attack window.

• Monitor transactions: If your applications interact with cryptocurrency wallets or Web3 APIs, monitor transactions closely for any unusual activity.

• Enable 2FA: Strengthen your own account security by enabling Two-Factor Authentication and using a hardware key if possible. Be extremely wary of any emails, even those that look legitimate, asking you to update credentials or click on links. Instead, navigate directly to the official website.

While the quick detection and response limited the overall damage, this incident highlights a significant vulnerability. A single successful phishing attack against a high-profile maintainer can have a cascading effect across the entire software ecosystem, potentially exposing millions of end-users to financial loss. This event underscores the need for continuous vigilance, enhanced security protocols, and collaborative efforts between security researchers, platform providers, and the developer community to secure the digital supply chain.

Although on Qix's side the issue seemed to have been "resolved" hours later, it is worth mentioning that other npm maintainers were also affected, as stated here: