Billions at Risk, Pennies Stolen: Inside the npm Phish that Shook the Web
Executive Summary
On September 8, 2025, the cryptocurrency ecosystem faced one of its most severe security threats when the account of a long-trusted maintainer known as Qix (Josh Junon) was hijacked through a phishing email, and 18 popular packages were altered with malicious code. Those packages include chalk, debug, and ansi-styles, which together represent more than two billion weekly downloads. This supply chain attack represents the largest npm attack ever recorded, injecting sophisticated cryptocurrency-stealing malware into core JavaScript libraries used by millions of developers worldwide.
The compromised packages contained malware specifically designed to target cryptocurrency wallets across multiple blockchains, including Ethereum (EVM), Bitcoin, Litecoin, Solana, and Tron. Despite having unprecedented access to millions of systems globally, the attacker's actual financial gain appears minimal, highlighting both the severity of the breach and the importance of rapid community response in mitigating large-scale threats.
Background: Why compromising “Qix” was a global-fire-alarm moment
Qix (Josh Junon) is a long-time maintainer of chalk and debug (plus color/ANSI utilities) that sit at the base of enormous dependency trees, from CLIs to framework tooling to production servers. Even tiny patch bumps ripple through CI pipelines and front-ends worldwide. Qix’s own profile notes he co-maintains two of the top ten JavaScript packages on npm.
The criticality of this compromise cannot be overstated. For e.g, Chalk is a terminal styling library used across virtually every JavaScript project, while Debug provides debugging utilities that are integral to development workflows. When these core dependencies are compromised, the attack surface extends to every application that relies on them, creating a cascading effect throughout the entire technology ecosystem.
Security vendors pegged weekly downloads of affected packages in the hundreds of millions; chalk alone is ~299M/week and debug ~47M/week. That’s a supply chain blast radius of historic scale.
For the crypto community specifically, this attack was particularly dangerous because many decentralized applications (dApps), wallet interfaces, and trading platforms rely heavily on JavaScript and Node.js infrastructure. The malware was specifically crafted to target cryptocurrency transactions, making it a direct threat to users' digital assets.
Initial Compromise: A look-alike npm “support” domain
The maintainer (Qix) was phished via support@npmjs[.]help (a typosquatted domain), lured to a bogus 2FA page that captured username, password, and one-time codes and exfiltrated them to attacker infrastructure. SEAL Intel documents the infrastructure (BunnyCDN buckets and websocket-api2.publicvm[.]com) used in the capture flow.
Once the attacker gained control of qix's npm account, they published malicious versions of 18 different packages. The attack was executed with surgical precision, injecting payload code that would only activate in browser environments where cryptocurrency wallets might be present. The payload doesn't actually run if typeof window == undefined as is the case in NodeJS runtime, showing the attacker's understanding of where their malware would be most effective.
The First Alert: Community detection and response
The security community's rapid response was crucial in limiting the attack's impact. Thanks to the hackers too, as their mistakes caused crashes in CI/CD pipelines, which led to early detection and limited impact. Aikido Security flagged it as the largest npm attack ever recorded, with 18 packages like chalk, debug, and ansi-styles hacked to hijack crypto wallets via injected code. Security researchers quickly identified the malicious payload and began analyzing its capabilities. SEAL Intel published a detailed timeline and sample payload the same day, time-stamping the compromise to ~9:30 a.m. ET and giving indicators of compromise (IoCs).
GitHub issues were immediately opened on the affected repositories, with developers reporting the compromise across multiple channels. Malicious payload is on line 11 of src/index.js was identified in the chalk package, providing the community with specific locations to examine and verify the threat.
Decoding the Malicious Package: Understanding the malware
The malware demonstrated sophisticated cryptocurrency-targeting capabilities through two primary attack vectors:
Passive Address Swapping
Uses "lookalike" addresses (via string-matching) to make swaps less obvious. This technique involves monitoring user input and clipboard content for cryptocurrency addresses, then substituting them with attacker-controlled addresses that appear similar to the original. The visual similarity makes it difficult for users to detect the substitution during casual inspection.
Active Transaction Hijacking
The more dangerous component involved real-time transaction manipulation & hijacking. Alters Ethereum and Solana transaction parameters (e.g., recipients, approvals, allowances). Even if the UI looks correct, the signed transaction routes funds to the attacker. This means that even when users carefully verify transaction details in their wallet interface, the underlying transaction data could be modified before signing.
Target surface
The hard-coded replacement lists span multiple chains, not just EVM:
EVM chains (Ethereum and EVM-compatible):
0x…addressesBitcoin: legacy
1…/3…and Bech32bc1…formatsLitecoin:
L…/ltc1…formatsSolana: base58 public keys
Tron:
T…addresses
The corpus contains a large set of candidate sink addresses, with only a subset observed “activated” so far; many remain dormant. The practical emphasis of the code paths, and early on-chain activity, skews EVM-first, with multi-chain fallbacks present for broader coverage.
Analyzing the Malware
Our team conducted a thorough analysis of the malicious code to understand its nature and how it operates.
Blockscope Traces: Early on-chain signals
Despite the massive scale of the potential attack surface, our analysis reveals that the attacker's actual profits were surprisingly minimal, below $500. The first wallet activity was detected for address 0xFc4a4858bafef54D1b1d7697bfb5c52F4c166976, which showed limited transaction activity, stealing nearly $428.74 worth of ETH from two users, which have been attributed as some Open sea users.
The address 0x93Ff376B931B92aF91241aAf257d708B62D62F4C has shown activity on the Base network, where it is reported to have stolen small amounts, often just a few cents.
Also, there have been some reports of losses linked to this malware attack on solana, stealing ~285 SOL, but no verified evidence have been found.
Notably, most of these addresses remain inactive, with some being activated but not used for malicious purposes. This suggests either the attack was discovered and mitigated before significant damage occurred, or the attacker chose not to exploit their position fully.
A comprehensive list of potentially hacker addresses has been compiled and is available at: https://gist.github.com/jdstaerk/f845fbc1babad2b2c5af93916dd7e9fb
How the Attackers could have caused far more damage (and why they couldn’t)
Just for clarity: this is a defensive analysis, not a how-to. Our goal is to examine what went wrong and what went right from an OPSEC perspective.
Scope vs. Execution context: With publish rights over ultra-popular packages, the hacker had theoretical reach into billions of browser sessions. But the payload didn’t target Node runtimes (no persistence via
postinstall, no token/secret harvesters for servers). That choice drastically limited blast effectiveness.No Stealth on CI: The code’s
fetchoverride threw errors in automated builds, creating noisy, self-reporting failures that outed the compromise rapidly and raised alarm.Rapid Community Detection: Issues and advisories landed within hours, giving defenders concrete IoCs and fixed versions.
The upshot; Enormous potential control surface, but operational choices + community speed converted a doomsday vector into a costly cleanup drill.
Conclusion
This was a near-miss attack with a planetary blast radius, the largest npm supply chain attack in history, compromising 18 packages with over 2 billion weekly downloads through a successful phishing attack on a maintainer. Crypto users are urged to take extreme care as NPM attack hits core JavaScript libraries. Despite the massive potential impact, actual losses were minimal (under $500 verified).
The malware was designed to hijack crypto transactions by intercepting wallet APIs and swapping addresses, but its browser-only targeting and noisy implementation limited effectiveness.
The real takeaway: we witnessed what a disciplined hacker with better tradecraft could have accomplished. One compromised maintainer nearly weaponized billions of JavaScript sessions. This was a stress test of our defenses, not a victory, and the next attempt may not be as sloppy.
Written by: Tushar Tiwari, Blockchain Forensics Analyst @ Blockscope
Disclaimer: Best Effort Work
This report reflects our best-effort analysis based on information available as of publication. Please note:
Data limitations: Sources may be incomplete and the dataset can contain inaccuracies, omissions, or errors.
Subject to change: New or updated evidence may emerge that could materially alter parts of this report.
Interpretive nature: Findings and conclusions are based on our current understanding and may evolve over time.
No guarantees: While we’ve taken reasonable steps to ensure accuracy, we cannot guarantee that all information is fully correct or complete.
This document should be treated as a snapshot of knowledge at the time of writing and may be revised if reliable new information becomes available.
Last updated