The math is unforgiving. A properly generated BIP39 mnemonic offers 2^128 or 2^256 possible combinations. The affected wallets offered 2^39. That is not a rounding error. That is a reduction of the search space by a factor of roughly 10^27 โ the difference between a vault door and a paper curtain. Over the past three months, attackers have walked through that curtain and extracted at least $5.69 million. The number is a floor, not a ceiling. Coinspect's analysis covered 2,000 seeds across five wallet brands. The actual exposure is likely larger. Read the code, not the pitch deck. The pitch deck for these wallets never mentioned that their random number generation was compromised by a dependency they never audited.
The vulnerability lives in CryptoJS, a JavaScript cryptography library that has been a default choice for countless projects. The flaw was introduced in 2014, when a developer responded to a GitHub issue by modifying the WordArray.random() function. The intent was benign. The implementation was catastrophic. Instead of drawing entropy from a cryptographically secure source, the function produced output with severely limited randomness. The search space collapsed from astronomical to merely difficult. For an attacker with modest computing resources, enumerating all possible mnemonics became feasible. For an attacker with a GPU cluster, it became trivial.
This is a supply chain failure. The wallet developers who integrated CryptoJS did not write the flawed code. They did, however, fail to verify what they were shipping. Modern wallets use window.crypto.getRandomValues(), a browser-native API that draws from the operating system's entropy pool. The affected wallets โ Bexo, NanChat, Bitcoin Libre, RRWallet, and Milo โ did not. They trusted a library that had been carrying a known defect for nearly a decade. Complexity hides the body. The complexity here was not in the wallet's own codebase. It was in the dependency tree, buried one level deep, invisible to users and, apparently, to developers.
The affected projects responded in predictably divergent ways. Bexo, NanChat, and Bitcoin Libre issued fixes. NanChat went further, proactively notifying users and advising migration. RRWallet and Milo chose a different path: they shut down. That is not a responsible exit. That is an evasion of liability. When a wallet project ceases operations rather than remediating a vulnerability that has already drained user funds, it signals that the developers understood the severity of the problem and chose to walk away from the consequences. Users of those wallets are now holding assets generated by software that no longer exists, with no vendor to contact and no patch to apply.
The attack pattern deserves scrutiny. Coinspect's timeline places the thefts between May and July. That is not a single opportunistic grab. That is a sustained, automated campaign. The attackers enumerated seed phrases, derived addresses, and checked for balances. This process is fully scriptable. The fact that it continued for months suggests the operators were methodical, patient, and confident that their window would not close. They were correct. The window remains open for anyone who generated a mnemonic with the affected software and has not yet migrated.
Here is the critical limitation of the fixes: updating the application only protects newly generated mnemonics. It does nothing for seeds already in circulation. A weak mnemonic generated in 2021 and imported into a hardware wallet in 2025 remains weak. The vulnerability is baked into the entropy, not the software. This is the "generate once, compromised forever" property of cryptographic keys. There is no patch for a bad random number. There is only migration. Users who ever used these wallets must generate new seeds with audited software, transfer their assets, and abandon the old addresses permanently. Anything less is a standing invitation to theft.
Based on my audit experience, this pattern is distressingly familiar. I have seen projects spend six figures on marketing while allocating nothing to dependency review. The 2017 ICO era was full of such cases. The lesson from that cycle was supposed to be that security is a prerequisite, not an afterthought. Yet here we are in 2025, dissecting a vulnerability introduced in 2014, exploited in 2025, and still not fully remediated. The industry's institutional memory is short. The attackers' memory is not.
Now, the contrarian angle. The bulls on this story have a point, and it is worth acknowledging. The affected wallets are marginal players. Their combined market share is negligible. MetaMask, Trust Wallet, and the major hardware wallet vendors were not impacted. For the mainstream user, this event changes nothing about their immediate security posture. The narrative that "self-custody is unsafe" is a misreading of the data. Self-custody is unsafe when implemented poorly. The flaw here is not in the concept of holding your own keys. The flaw is in a specific library function and the developers who failed to scrutinize it. That distinction matters. Conflating the two plays directly into the hands of those who would prefer users to surrender custody to centralized intermediaries.
There is also a genuine positive signal in this event: the security research community functioned exactly as it should. Coinspect identified the vulnerability, traced it to its root cause, quantified the damage, and released a public tool โ Unlukey โ that allows users to check whether their own mnemonics are compromised. That is the white-hat ecosystem operating at full effectiveness. The disclosure was responsible. The analysis was rigorous. The remediation guidance was actionable. This is the industry's immune system responding to an infection. It did not prevent the initial outbreak, but it is containing the spread.
The broader implication is uncomfortable. CryptoJS is not an obscure library. It is widely used across the JavaScript ecosystem, not just in wallets. Any project that relied on WordArray.random() for key generation, session tokens, or any security-sensitive operation is potentially exposed. The disclosed wallet list is likely incomplete. The actual blast radius may extend well beyond the five named projects. I would advise any developer reading this to audit their dependency tree today, not next quarter. Search for CryptoJS. Check which functions you are calling. If you are using WordArray.random() for anything security-critical, replace it immediately with a CSPRNG. The cost of that audit is trivial compared to the cost of a compromise.
Regulatory attention is the next shoe to drop. This is not a securities classification issue. It is a consumer protection issue. When software defects cause direct financial loss to users, regulators take notice. The affected wallet developers face potential civil liability. The ones who shut down may have hoped to avoid that exposure. They will not. Class action lawyers are already familiar with the crypto landscape. This case writes itself: a known vulnerability, a decade-old defect, and millions in user losses. The developers who chose to disappear rather than remediate have made themselves the most attractive targets.
What should users do? The answer is unambiguous. If you ever used RRWallet, Milo, Bexo, NanChat, or Bitcoin Libre, assume your mnemonic is compromised. Generate a new seed using a hardware wallet or a reputable software wallet that uses window.crypto.getRandomValues(). Move your assets. Do not reuse the old addresses. Do not keep a small balance as a "test." Attackers monitor for exactly that behavior. The migration is inconvenient. The alternative is losing everything.
What should developers do? Audit your dependencies. Not just the ones you wrote. The ones you imported. The ones your dependencies imported. Supply chain security is not a buzzword. It is the difference between shipping a product and shipping a liability. The CryptoJS flaw was introduced in 2014 and exploited in 2025. That is an eleven-year window. The next vulnerability could be shorter. The next exploit could be larger. The next victim could be you.
The market will move on. The news cycle will find a new story within a week. But the 2^39 problem remains, embedded in every mnemonic generated by the affected software, waiting for an attacker to enumerate it. The funds already stolen are gone. The funds still at risk are a choice. Migrate or wait. The attackers are not waiting. They are enumerating. The question is not whether they will find the remaining weak seeds. The question is whether the owners of those seeds will move first. Trust nothing. Verify everything. And if you have any doubt about the entropy behind your mnemonic, treat it as compromised. The cost of paranoia is a few hours of migration. The cost of complacency is everything you hold.