# CryptoJS Weak RNG Behind $5.7 Million in Crypto Wallet Drains
## The Threat
A 12-year-old entropy bug buried inside the popular CryptoJS JavaScript library has been confirmed as the mechanism behind a wave of crypto wallet thefts that blockchain security firm Coinspect has been tracking under the name "Ill Bloom." The culprit is CryptoJS.lib.WordArray.random() — a function that looked like a cryptographic random number generator but was seeded from Math.random(), a decidedly non-cryptographic source. Wallet apps that used it to generate BIP39 recovery phrases handed attackers a search space small enough to enumerate on commodity hardware.
The numbers are stark: entropy that should have provided 2^128 or 2^256 security was effectively reduced to 2^39 or 2^47. Coinspect reproduced the full attack chain — enumerate outputs, convert to BIP39 phrases, derive addresses, cross-reference against public blockchain data — and verified the approach works. Measured theft across two documented sweeps since late May totals at least $5.7 million, with Coinspect explicitly noting that figure is a lower bound.
What makes this particularly ugly is the library's own changelog. CryptoJS actually fixed this once: versions 3.2.0 and 3.2.1, released in 2014, switched to native cryptographic randomness. Then version 3.3.0 reverted the change because it was considered a breaking update. Any project that upgraded within the 3.x line could have silently moved from a safe release back to a vulnerable one. The bug wasn't permanently corrected until version 4.0.0 in February 2020 — six years after the initial botched fix.
## Severity and Impact
| Field | Detail |
|---|---|
| Advisory ID | GHSA-rg76-677x-56q9 |
| CVSS Score | 9.0 (Critical) |
| CWE | CWE-338 — Use of Cryptographically Weak PRNG |
| Attack Complexity | Low (enumerable search space on standard hardware) |
| Authentication Required | None — phrases guessable offline |
| User Interaction | None (victim already generated vulnerable phrase) |
| Exploitability | Active — confirmed $5.7M+ in measured thefts |
| Published | August 5, 2026 |
The advisory's package range covers all CryptoJS releases below 4.0.0, though the maintainer notes that carrying the dependency alone is not sufficient for exploitation — the vulnerable function must have been used to generate security-sensitive values such as wallet entropy.
## Affected Products
Vulnerable Wallet Applications (confirmed by Coinspect):
Underlying Library:
Coinspect explicitly cautions that this list is not exhaustive. Additional vulnerable wallets may have been removed from app stores or extension marketplaces before researchers could examine them, and vendors may have silently shipped patched versions that replaced vulnerable builds.
## Mitigations
The most important point — and one that will be missed by users focused on app updates — is that updating the application does not fix an already-generated recovery phrase. A phrase created by a vulnerable version of the generator remains guessable regardless of where it is subsequently imported, including into a hardware wallet. The entropy deficit is baked in at phrase generation time and cannot be corrected retroactively by PBKDF2, hashing, or any downstream processing.
Immediate actions for potentially affected users:
For developers:
ferrumnet/bip39 or a fork of it replaced native randomness with CryptoJS functions## References
---
## HackWire Analysis
The Ill Bloom disclosure is a case study in how the open-source supply chain fails at the exact moment it should protect users most. The vulnerability wasn't a zero-day someone found last week — it was a known-bad code path that the library maintainer actually corrected, then pulled back under the pressure of semver compatibility. Six years elapsed between the regression and the permanent fix. Every wallet application written during that window that happened to pick up the CryptoJS RNG for entropy generation was quietly handing attackers the keys.
What's worth sitting with here is the specificity of the exploitation. This wasn't a broad spray. Attackers enumerated the known-weak search space — 2^39 to 2^47 — against public blockchain data. They knew exactly which wallets were vulnerable, which addresses to target, and when to sweep. The two documented theft events since late May suggest active monitoring, not opportunistic scanning. Someone built infrastructure around this weakness and ran it as an operation.
The fork problem deserves more attention than it's getting. Coinspect identified ferrumnet/bip39 as one vector — a React Native fork that deliberately replaced upstream BIP39's native randomness with CryptoJS. Forks that downgrade cryptographic primitives to hit a dependency target or avoid a native module complication are exactly the kind of quiet supply chain risk that doesn't show up in a CVE scan. The upstream library might be safe; the fork in your lockfile might not be.
The discontinued wallets — RRWallet and Milo — present an unresolved problem. There is no fix path for users whose funds are still held under phrases generated by those apps. Those users need to act now, and the window between disclosure and attacker-awareness of the specific wallets is already closing.
— HackWire Editorial
---
## Related Coverage