It's not a hack. It's a math failure.
The search space for a properly generated wallet mnemonic should be 2^128 for 12 words, or 2^256 for 24 words. Those numbers are so large that brute-forcing them is a theoretical exercise โ the kind of thing physicists mention when they want to illustrate cosmic improbability.
Coinspect found wallets where that space collapsed to 2^39 or 2^47. That's not a rounding error. That's the difference between "impossible" and "a weekend project with a rented GPU cluster."
The vulnerability traces back to a single function in the CryptoJS library: WordArray.random(). The flaw was introduced in 2014, in response to a GitHub issue. Eleven years later, it has drained at least $5.69 million from users who did everything right. They generated a wallet, wrote down their mnemonic, stored it in a safe place, and never shared it with anyone. The code betrayed them anyway.
This is the story of how randomness fails, and what it means for an industry that treats self-custody as a sacred principle.
CryptoJS is one of the most widely used JavaScript cryptography libraries in existence. It's been embedded in thousands of projects โ wallets, dApps, backend services, even some enterprise tools. Its popularity made it a default choice for developers who needed cryptographic primitives without implementing them from scratch.
The specific flaw in WordArray.random() reduces the effective entropy of generated seeds to a fraction of what BIP39 requires. BIP39, the standard that defines how mnemonic phrases are generated, mandates a cryptographically secure pseudo-random number generator (CSPRNG). CryptoJS's implementation fell short of that requirement โ not by a little, but by orders of magnitude.
The affected wallets โ Bexo, NanChat, Bitcoin Libre, RRWallet, and Milo โ are not household names. That's precisely the problem. They're small, niche projects that relied on a popular library without auditing its internals. Modern wallets like MetaMask use window.crypto.getRandomValues(), a browser-native CSPRNG that draws from the operating system's entropy pool. The affected projects used a library function that was never designed for key generation.
Coinspect's analysis covered more than 2,000 seeds across five wallet brands. The actual blast radius is likely larger. The exposure depends on the software version used at the time of mnemonic generation, not the brand. Any wallet that used CryptoJS's WordArray.random() during the vulnerable window is suspect โ and the industry has no way to enumerate all of them.
This is a supply chain problem, not a wallet problem. The wallet developers integrated a library they trusted. The library had a flaw that had been sitting there for a decade. And the users โ the people who actually lost money โ had no way to know.
Let me be precise about what broke. The WordArray.random() function in CryptoJS was modified in 2014 to address a GitHub issue. The patch introduced a subtle bias in the random number generation. Instead of drawing uniformly from the full entropy pool, the function produced outputs with significantly reduced randomness.
For a 12-word mnemonic, the effective search space dropped from 2^128 to approximately 2^39. For a 24-word mnemonic, it dropped from 2^256 to approximately 2^47.
To put that in perspective: 2^128 is roughly the number of atoms in the observable universe. 2^39 is roughly the number of seconds since the Big Bang. One is a cosmic impossibility. The other is a computational exercise that a determined attacker can complete in days.
The attack was fully automated. Between May and July, attackers enumerated weak seeds, derived addresses, and checked for balances. This wasn't a targeted heist. It was a sweep โ a systematic scan of the entire vulnerable key space. The automation is the detail that should concern every security researcher: the attackers built a pipeline that could continuously monitor for new funds deposited into vulnerable addresses.
The $5.69 million that Coinspect tracked is a lower bound. The analysis covered only a subset of seeds and chains. Some funds may have already been laundered through mixers or privacy coins. The actual number is likely higher.
Here's the part that should worry you: updating the wallet application doesn't fix existing mnemonics. The vulnerability is baked into the seed itself. If you generated a mnemonic with a vulnerable version of these wallets, that mnemonic is permanently compromised. Importing it into a hardware wallet or a "secure" software wallet doesn't help. The seed is the seed. The entropy deficit is permanent.
This is what I call the "generate-and-forget" trap. Most users generate a wallet once, write down the mnemonic, and never think about it again. They assume the wallet software handled randomness correctly. In this case, the software didn't. And because the flaw was in a third-party library, the wallet developers may not have even known.
Based on my experience auditing ERC-20 contracts during the 2017 ICO boom, I can tell you that this pattern is more common than the industry admits. Small teams ship products that depend on libraries they don't fully understand. The libraries are popular, so the assumption is they're secure. Popularity is not a security audit.
I saw the same dynamic during the 2020 DeFi summer. Projects were forking Uniswap and SushiSwap code, adding their own tokenomics, and launching in weeks. Nobody was auditing the dependencies. The focus was on the smart contract logic โ the visible layer โ while the invisible layer of libraries and utilities went unexamined.
The response from the affected wallet teams has been uneven. Bexo, NanChat, and Bitcoin Libre patched their code. NanChat went further, proactively notifying users and advising them to migrate. RRWallet and Milo chose a different path: they shut down. That's not a fix. That's an exit.
Coinspect, the security firm that identified the vulnerability, also released a tool called Unlukey that lets users check whether their mnemonic is affected. That's the kind of practical response the industry needs more of โ not blog posts about "best practices," but tools that give users actionable information.
The counter-intuitive angle here is that this event is not actually about the wallets. It's about the entire supply chain of crypto infrastructure. The narrative forming in the market is "self-custody is dangerous" โ a convenient story for exchanges and custodial services that want to consolidate control. That narrative is wrong.
Self-custody isn't the problem. The problem is that we've built an ecosystem where a single flawed library function can compromise thousands of projects, and where the industry's response is to blame the victims for using "non-mainstream" wallets.
The real lesson is structural: the crypto industry needs supply chain security standards, not just smart contract audits. We audit the logic of DeFi protocols obsessively, but we barely glance at the dependencies underneath. The whitepaper is fiction; the code is fact. But the code's dependencies โ those are the unexamined layer.
This also connects to a broader pattern I've observed in the market. We keep building new layers โ L2s, app chains, modular blockchains โ while the foundational security of the tools users interact with every day remains fragile. It's the same logic that drives liquidity fragmentation: we're slicing already-scarce resources into thinner and thinner pieces, assuming the underlying infrastructure will hold. Sometimes it doesn't.
Arbitrage is just geometry disguised as finance. And this vulnerability is just probability mismanagement disguised as a wallet bug. The attackers didn't break cryptography. They exploited a geometric reduction in the search space โ a mathematical gift wrapped in a GitHub issue from 2014.
The next narrative shift won't come from a new L2 or a token launch. It will come from the industry finally treating wallet security as infrastructure, not an afterthought. Account abstraction, social recovery, multi-factor authentication โ these aren't features. They're survival mechanisms.
If you've ever used a non-mainstream wallet, check your seed. If you generated a mnemonic before 2024 with any wallet that relied on CryptoJS, assume it's compromised. Move your funds. Generate a new seed with a wallet that uses a proper CSPRNG.
The code doesn't care about your caution. It only cares about the math. And the math was broken.
The question isn't whether the next supply chain vulnerability will surface. It's whether the industry will be auditing its dependencies when it does โ or still polishing the visible layer while the foundation cracks beneath it.
Tags: Wallet Security, Supply Chain, CryptoJS, Mnemonic Vulnerability, Self-Custody, Blockchain Security, Entropy, BIP39
Prompt for illustration: A dramatic split-screen digital illustration showing a massive glowing geometric sphere (representing 2^128 search space) on the left, and a tiny, dim, cracked sphere (representing 2^39) on the right, connected by a thin broken chain link. Dark navy and electric blue color palette with subtle orange warning accents, futuristic fintech aesthetic, clean lines, high contrast, 16:9 aspect ratio.