Major npm Supply Chain Attack: Popular “color” Package Compromised to Steal Cryptocurrency

“

A sophisticated phishing attack against a key open-source maintainer led to malicious versions of widely-used JavaScript libraries being published on npm, putting millions of users at risk.

On September 8, 2025, the JavaScript ecosystem faced a significant security crisis. The npm account of developer Josh Junon (username qix) was compromised, leading to the publication of backdoored versions of multiple popular packages under his maintenance. This incident highlights the fragile nature of our open-source software supply chain and how targeted attacks against maintainers can have widespread consequences.

How the Attack Unfolded

The incident began approximately at 13:00 UTC on September 8, 2025. Attackers gained control of Josh’s npm account and started publishing malicious versions of his popular packages.

The open-source community’s vigilance proved crucial once again. Someone quickly noticed the suspicious updates and promptly alerted Josh through social media platforms.

Josh confirmed the breach, explaining that he fell victim to a convincing two-factor authentication (2FA) reset phishing email. He clarified that only his npm account was affected and that he had immediately contacted npm support to regain access.

The Deceptive Phishing Email

The attackers used a phishing email sent from the domain npmsj.help (registered just three days before the attack). The email cleverly disguised itself as an official npm security notification, claiming that users needed to update their two-factor authentication (2FA settings for security reasons.

The email stated: “Hi there! As part of our ongoing commitment to account security, we are requesting that all users update their Two-Factor Authentication (2FA credentials. Our records indicate that it has been over 12 months since your last 2FA update.” It threatened temporary account suspension if not completed by September 10, 2025.

The raw email has been made publicly available, and analysis suggests it was likely sent through the Mailtrap email testing service.

Which Packages Were Affected?

Security researcher Kevin Beaumont provided a list of known affected packages on Mastodon. These packages collectively had billions of downloads prior to the incident:

• supports-hyperlinks
• chalk-template
• simple-swizzle
• slice-ansi
• error-ex
• is-arrayish
• wrap-ansi
• backslash
• color-string
• color-convert
• color
• color-name

The color package alone receives approximately 31.7 million weekly downloads, demonstrating the potential scale of this attack.

What Did the Malicious Code Do? (Technical Analysis)

The complete malicious payload has been made publicly available. Initial analysis indicates that this code was not designed to run in server environments (like Node.js or Bun) or on developer machines, but specifically targeted browser environments.

This means the attack could only successfully steal funds if several specific conditions were met:

1. Maintainers of cryptocurrency websites or web applications had to upgrade to the compromised dependencies
2. These dependencies needed to be used in the front-end (browser) portion of the application
3. The cryptocurrency website would have needed to be built, packaged, and deployed with the malicious code
4. Users would have had to make transactions while the drainer was active

In simpler terms, if developers merely accepted a pull request that updated some dependencies and ran tests in CI, then no actual damage may have occurred yet. However, the security community is still working to fully understand the payload’s complete functionality and all affected packages.

De-obfuscating the code provides clear insight into its malicious behavior.

In short, its primary purpose was to manipulate cryptocurrency addresses, redirecting funds to attacker-controlled wallets.

Specific Attack Methods

1. Network Request Hijacking: The code hooked into fetch and XMLHTTPRequest functions to monitor all network responses. Any cryptocurrency addresses found in response bodies that resembled Bitcoin, Solana, Litecoin v2, and others were dynamically replaced with one from the attacker’s predefined list of addresses.

2. Targeting MetaMask and Other Wallets: The code attempted every 500 milliseconds to check if any Ethereum accounts had been authorized through MetaMask or similar wallets. Upon detection, it would hijack the window.ethereum.request method to manipulate specific transaction requests:

   • approve(address,uint256): Replaced the target address and set the approval amount to the maximum limit. This path also logged the name of decentralized exchanges (DEX) such as Uniswap, PancakeSwap, 1inch, and SushiSwap.
   • permit(address,address,uint256,uint256,uint8,bytes32,bytes32): Replaced the target address and maximized its value.
   • transfer(address,uint256): Replaced the target address while maintaining the original transfer amount.
   • transferFrom(address,address,uint256): Replaced the target address while maintaining the original transfer amount.

3. Targeting the Solana Blockchain: The code also contained pathways for handling Solana transactions, modifying relevant fields to a specific string: 19111111111111111111111111111111. However, the effectiveness of this particular approach remains unclear.

This attack was particularly insidious because it didn’t modify the content of requests sent by users (request body), but instead modified the content returned by servers (response body). It likely targeted websites or applications that used API calls to retrieve recipient addresses before initiating transfers through other means.

Current Status and Response

As of September 8, 2025, 17:19 UTC

• npm officials have contacted Josh and indicated they are working to remove the malicious packages.

As of September 8, 2025, 17:11 UTC

• Josh remained locked out of his npm account.
• The popular affected package chalk had been patched by its co-maintainer Sindre Sorhus.
• However, malicious versions of other packages (like simple-swizzle) remained available on npm, not yet taken down.

The response time from npm officials faced criticism from the community during this critical security event. Josh had not received any email response from npm nearly two hours after the incident began, potentially giving attackers a longer window to cause harm.

Lessons Learned and Implications

This compromise of the color npm package and others serves as another wake-up call regarding open-source software supply chain security. It reveals several critical issues:

1. Developer Accounts Are Vulnerable Points: Attackers no longer need to directly breach large platforms; targeting individual maintainers through phishing can impact countless projects.
2. Complexity of Dependencies: The compromise of a fundamental package can quickly propagate upward through dependency trees, affecting numerous downstream applications. Many developers might not even realize they indirectly depend on color.
3. Platform Response Mechanisms: During critical security events, official platforms require faster, more transparent response and handling procedures to protect the entire ecosystem.
4. Security Awareness is Essential: For all developers, maintaining vigilance against phishing emails, enabling and securely managing 2FA, and regularly reviewing dependencies are essential self-protection measures.

For general users, this incident primarily affects developers and users of cryptocurrency-related websites and applications. When conducting any on-chain transactions recently, exercise extra caution, double-check recipient addresses multiple times, and pay attention to security advisories issued by the community.

The strength of the open-source ecosystem lies in collaboration, but its vulnerability does too. Securing every aspect requires concerted effort and vigilance from platforms, maintainers, and developers alike.

Frequently Asked Questions

1. Is my project affected?
If your project directly or indirectly depends on any packages listed above (like color, chalk, etc.) and you recently (after September 8) updated their versions, your project might contain malicious code. Immediately check your package-lock.json or yarn.lock files, and revert to known safe versions.

2. What should I do as a developer right now?

• Immediately check your project dependencies to confirm if you’re using the recent malicious versions of affected packages.
• Revert dependencies to previously known safe versions.
• If you ran projects that might have contained the malicious code, check your systems for any unauthorized access or transactions.
• If you maintain libraries, audit your dependencies and update to secure versions.

3. Could this attack steal files or personal data from my computer?
Based on current analysis, the primary goal of this malicious code was to manipulate cryptocurrency transactions within browsers. Currently, there’s no evidence suggesting it aimed to steal local files or personal data. However, its ultimate capabilities depend on the attacker’s intentions, so maintaining vigilance is necessary.

4. How can I avoid such phishing attacks?

• Never click links in emails to reset 2FA or log into accounts. Always navigate directly to official websites to perform these actions.
• Carefully examine sender email addresses; official communications typically come from company domains.
• Enable 2FA using hardware security keys or authenticator apps, which are more secure than SMS-based 2FA.
• Maintain skepticism toward any emails claiming “urgency” or requiring “immediate action.”

5. What will npm officials do with these malicious packages?
Typically, the npm security team will remove malicious packages after confirmation, preventing further installation. However, systems that have already installed malicious versions require developers to manually check and clean them up.