I want to alert you to a major security incident that is currently making waves in the JavaScript community. We are dealing with a software supply chain attack in the npm ecosystem: no fewer than 18 highly popular packages (including chalk and debug) were compromised through a hijacked maintainer account. As a result, malicious versions of these libraries were published on September 8, 2025, containing code designed to intercept cryptocurrency transactions. Collectively, these packages see over 2 billion downloads per week, making this incident one of the most far-reaching npm compromises ever by potential impact.
Attack background and discovery
The incident began when an npm maintainer’s account (that of Josh Junon, aka “Qix”) was compromised via a targeted phishing campaign. The maintainer received an email impersonating npm’s support (support@npmjs.help), prompting him to update his two-factor authentication (2FA) settings. Unfortunately, by following the link to a counterfeit npm login page, he inadvertently provided his credentials and 2FA one-time code to the attackers. With this access, the adversaries logged in to his npm account, pushed malicious updates to the packages he maintains, and changed the account’s associated email address to lock him out.
In total, 18 popular JavaScript modules were affected by this breach. This includes widely used tools like chalk (for console text styling) and debug (for debug logging), as well as a host of related dependencies (e.g., ansi-styles, supports-color, has-ansi, strip-ansi, etc.). Starting at approximately 13:16 UTC on September 8, the attackers published malicious versions for each of these packages. The anomaly was quickly caught by Aikido Security’s monitoring system, which flagged the suspicious updates. Aikido researchers alerted the maintainer via the Bluesky social network, and by 15:15 UTC he had acknowledged the phishing compromise and begun removing the corrupted releases. Thanks to this swift, coordinated response, the exposure window was kept short: within a few hours, the malicious package versions were taken down from npm and replaced with clean versions.
A crypto-stealing malware in popular libraries
The code injected by the attackers essentially functioned as a sophisticated browser-based malware hidden inside the compromised packages. In practice, whenever a web application included one of these tainted libraries, the malicious script would execute on end-user machines within the browser context. It was engineered to subvert key web APIs and wallet interactions in order to spy on and tamper with cryptocurrency-related activity:
- It monitors for the presence of crypto wallets (for instance, checking for
window.ethereumwhich is used by Ethereum browser wallets like MetaMask) and hooks into wallet API calls. - It injects itself into network request functions such as
fetchandXMLHttpRequest, allowing it to silently inspect data being exchanged with backend servers. The malware scans responses for any substrings that resemble cryptocurrency addresses (Ethereum, Bitcoin, Solana, Tron, etc.). - When it detects a transaction or a wallet address in use, the malware substitutes the intended destination with one controlled by the attacker. It employs “lookalike” addresses and similarity algorithms (e.g. using edit distance calculations) to replace the legitimate address with a malicious one that closely resembles it, making the swap less obvious at a glance.
- Right before a user finalizes a crypto transaction (for example, when a wallet is about to sign an
approveortransfercall on Ethereum), the malicious code alters the transaction parameters in real-time. This means even if the application’s UI displays the expected recipient and amount, the transaction that gets signed could have been modified in the background to redirect funds to the attacker’s account. - The malware takes care to remain stealthy: if it detects an active wallet session, it avoids doing anything that would obviously alert the user (such as visible changes in the interface). It persistently runs in the background to intercept further actions, all while trying not to disrupt the normal user experience.
The clear objective of this payload was to siphon cryptocurrencies. Notably, the malware did not attempt to execute any payload outside of the browser context: it did not read files from the host system, steal developer credentials, or install backdoors. The attack’s scope was deliberately confined to digital assets moving through web applications that included the compromised code.
Impact and scope of the incident
Although this attack was remarkable in its potential reach (the libraries in question are embedded in countless projects and websites), the actual impact appears to have been limited so far. The campaign was halted quickly, greatly reducing the number of applications that could have pulled in the poisoned updates. At the time of writing, no significant cryptocurrency theft has been reported as a result of this incident. In fact, initial analyses suggest the attackers only managed to steal an almost negligible amount of funds (on the order of mere cents). This paradox – an attack theoretically affecting billions of downloads yet causing virtually no financial damage – comes down to a combination of rapid detection and a relatively narrow targeting (crypto transactions) which limited the window of victims to those performing such operations during the brief compromise period.
That said, the incident could have been far more devastating. By compromising the software supply chain in this manner, malicious actors could just as easily have inserted a much more destructive payload: for example, one that harvested developer authentication tokens (for npm, GitHub, SSH/API keys) or planted persistent malware on user systems. Security experts have noted that the ecosystem likely “dodged a bullet” in this case. This event highlights the vulnerabilities inherent in open source supply chains when maintainers are targeted. It’s also worth noting that this comes only a few weeks after another phishing-based compromise of a popular npm package (nx in late August 2025), indicating that such supply chain attacks are on the rise.
Response and security recommendations
In the wake of this alert, security teams (CERTs, SOCs) and numerous developers worldwide scrambled to assess their exposure and secure their environments. If you use npm packages in your JavaScript projects, I strongly recommend taking the following actions without delay:
- Identify any usage of the affected packages: Review the list of compromised modules (e.g.
chalk,debug,ansi-styles,supports-color,strip-ansi,has-ansi,wrap-ansi,color-string, etc.) and check whether your applications or their dependencies include them. The malicious releases have specific version numbers (for example,chalk5.6.1,debug4.4.2, etc. – all published on 2025-09-08). - Update or rollback to safe versions: If you find that any of your projects pulled in one of those compromised releases, replace them immediately. This may involve upgrading to a patched safe version published by the legitimate maintainer or temporarily downgrading to the last known good version. The npm security team has removed the bad releases from the registry, so performing a fresh install should now fetch a clean version.
- Purge caches and reinstall dependencies: To be thorough, clear your package manager’s cache (
npm cache clean --force) and reinstall your Node.js dependencies from scratch. This ensures that no remnants of the malicious code linger in your build or production environment. - Leverage lockfiles and pin versions: This incident underscores the importance of using a lockfile (
package-lock.jsonor equivalent) to pin exact dependency versions. By locking versions, you prevent unexpected upgrades to a compromised release. Of course, this doesn’t eliminate the risk (you will eventually need to update), but it lets you control the timing of updates and review changes before deploying them. - Be vigilant with crypto transactions: If your application deals with cryptocurrency (e.g. integrating a wallet or processing crypto payments), exercise heightened caution in the coming days. Advise your users to double-check destination addresses before confirming any transaction. Internally, consider inspecting your web application logs for any anomalies in network calls or transaction data around the timeframe of September 8.
- Educate maintainers and developers: Within your organization, reinforce security awareness, especially regarding targeted phishing. This incident is a textbook example of how a convincing email can trick even an experienced maintainer. Emphasize best practices: avoid clicking on unsolicited links, verify URLs before entering sensitive information, and favor physical security keys (e.g. YubiKeys) for 2FA on critical accounts (GitHub, npm, etc.).
- Strengthen software supply chain defenses: Consider tools and procedures to vet third-party dependencies. Malware-scanning solutions, threat intelligence feeds, or behavior analysis tools can help flag suspicious package updates more promptly. Additionally, the community is discussing measures such as provenance attestation for highly popular packages, to ensure that an npm release is verifiably coming from a legitimate build process and not from a direct account compromise.
In summary, this widely publicized “npm flaw” serves as a stark reminder that even the most trusted open-source components can be subverted at the source. As a CISO, SOC analyst, or developer, it is crucial to stay alert to security advisories affecting your software supply chain and to react swiftly to protect your users and data. In this case, the damage was contained and the attack’s aim was relatively narrow and financial. However, it underscores the need for collective vigilance in the open-source ecosystem and for enhanced safeguards to secure the software supply chain.
Enjoy !
Sources
- Aikido Security – “npm debug and chalk packages compromised”, blog post by Charlie Eriksen (September 8, 2025).
- Krebs on Security – “18 Popular Code Packages Hacked, Rigged to Steal Crypto”, article by Brian Krebs (September 8, 2025).
