Ill Bloom's Root Cause Named: A 12-Year-Old CryptoJS Function Fed Weak Randomness to 5 Wallet Apps

What Happened

The Ill Bloom wallet drains now have a confirmed root cause. Security research firm Coinspect, which has tracked the thefts since May, identified CryptoJS.lib.WordArray.random() as the weak random number generator (RNG) that produced predictable recovery phrases in at least 5 cryptocurrency wallet applications.

The function sits in CryptoJS, a JavaScript cryptography library that has been in wide use for over a decade, and it supplied predictable output where a 12-word BIP-39 recovery phrase requires 128 bits of entropy, leaving a search space small enough for attackers to enumerate. On August 5, CryptoJS maintainer Evan Vosberg published a GitHub security advisory rating the flaw Critical with a Common Vulnerability Scoring System (CVSS) score of 9.

0, according to The Hacker News. Coinspect has confirmed 5 affected applications: RRWallet and Milo, both discontinued with no fix coming; Bexo, fixed in version 20.1.0; NanChat, fixed in 1.3.0; and Bitcoin Libre, fixed in version 4 back in July 2024.

The money is already moving. Coinspect's on-chain analysis puts measured theft across 2 coordinated sweeps at a lower bound of roughly $5.7 million. The first, on May 27, drained about $3.14 million from 431 wallets in a single day across Bitcoin, Ethereum, Tron, Rootstock, and Polygon.

A second run between May 30 and July 13 took roughly $2.55 million from addresses tied to 522 seeds. Coinspect's July investigation counted 2,114 vulnerable wallets its methods could identify, some generated as early as 2018, and the firm cautions that both the wallet list and the loss figures are floors rather than totals: several affected apps had already been removed from app stores and could not be examined, and sweeps on additional networks may have gone unmeasured.

Coinspect also published a checking tool at illbloom.org where holders can test whether their addresses fall in the exposed set.

A wallet is only as random as the function that seeded it. Ill Bloom's victims did everything right at every layer they could see; the failure lived in the one layer no user can inspect.

The Library Every Layer Trusted

The reason this entry belongs in the Trust Inversion series is the location of the failure. A cryptography library is the layer developers import specifically to avoid writing their own primitives; do not roll your own crypto is the first rule of the discipline, and the affected wallet teams followed it.

The function they called did not error, stall, or return anything visibly wrong. It produced valid-looking output that flowed into valid BIP-39 phrases, valid private keys, and valid addresses that held funds for years. Every layer a developer or user could inspect looked correct.

The defect lived in the one property nobody can eyeball: whether the randomness was actually random. There is a real scope limit here, per The Hacker News: an application is affected only if it used the function to generate security-sensitive values, and carrying the dependency alone is not exposure.

That nuance is also why the problem survived 12 years of the library being everywhere. The bug was not in what the code did, but in what it was trusted to be.

The other structural fact is that the damage cannot be repaired in place. Entropy lost at generation is lost permanently: hashing a predictable input, deriving keys from it, or updating the library afterward produces the same predictable wallet. A patched app protects only wallets created after the patch.

That makes the 2 discontinued apps, RRWallet and Milo, the sharpest edge of this incident. Their users have no vendor to push an update, staff a support desk, or send a warning email. Coinkite spent last week emailing every Coldcard customer it could reach about that device's seed flaw, and phishers promptly impersonated the outreach; Ill Bloom's orphaned users face the opposite problem, because no list of them exists at all.

The people most exposed are structurally the least likely to ever hear about it.

The Attackers Were Months Ahead of the Advisory

Reconstruct the timeline and an uncomfortable ordering appears. The first coordinated sweep hit on May 27. Coinspect's public investigation naming Ill Bloom landed in July, and the root cause identification and Critical advisory arrived August 5. Whoever ran the May sweep had independently found the weakness, enumerated the reduced seed space, matched candidate seeds against funded addresses on 5 chains, and industrialized the harvest before the first public warning existed.

Defenders were not racing the disclosure; they were racing an exploitation campaign that was already roughly 10 weeks old when the advisory published. The advisory now cuts both ways, as advisories always do: it tells every remaining exposed holder to move, and it tells everyone else exactly where to look.

Coinspect has withheld exploit details, but the sweep pattern suggests the operators who matter never needed them.

The proximity to the Coldcard incident is hard to ignore, and the honest reading is structural rather than coincidental. 10 days ago, Coldcard's Mk3 seed flaw put the same failure class on the hardware side (see '594 BTC Swept in 25 Minutes: Coldcard's Mk3 Seed Flaw Turns the Hardware Wallet Inside Out'): a device RNG that produced guessable seeds, discovered through on-chain sweeps rather than audit.

Coinspect states that current evidence shows seeds generated on hardware wallets are not affected by Ill Bloom, and that most current software wallets are also not vulnerable. Both statements are reassuring, and both are narrower than they sound. The common thread across the 2 incidents is not a form factor.

It is that seed entropy is unverifiable by inspection, generated once, and trusted forever, and that in both cases the first reliable detector of bad randomness was the theft itself.

What This Means for You

The immediate action is specific. If you ever generated a wallet in RRWallet, Milo, Bexo before version 20.1.0, NanChat before 1.3.0, or Bitcoin Libre before version 4, treat that recovery phrase as compromised today. Updating the app does not help. Receiving funds at a new address under the same seed does not help.

The only remediation is generating a fresh seed on a maintained, widely audited tool and moving funds to it, promptly: a public Critical advisory tends to accelerate whatever sweeping remains. Coinspect's checker at illbloom.org can test address exposure, but if you used one of the named apps in a vulnerable version window, migrate on principle rather than waiting for confirmation.

The skeptical response writes itself: 2 entropy failures in 2 weeks, one in a flagship hardware wallet and one in a mainstream cryptography library, reads like an argument that self-custody is too fragile for ordinary holders and a custodian is safer. The documented pattern supports a narrower conclusion.

Ill Bloom's exposure concentrated in small, in some cases abandoned, wallet apps; maintained mainstream software and hardware-generated seeds were unaffected here, and the remediation (rotate the seed, move the funds) required no one's permission, no support ticket, and no identity check.

Custody replaces an inspectable risk with a contractual one, and this site documents weekly what custodial contact points cost when a freeze authority, a bankruptcy, or a breach arrives. Self-custody did not fail here. Unverified seed generation did.

Posture, then, in order of leverage. Generate seeds only on maintained, widely reviewed tools, and prefer devices that support verifiable entropy: dice-roll seed generation, which several hardware wallets support, takes the unverifiable RNG out of the loop entirely. At meaningful size, multi-sig across devices from different vendors bounds any single vendor's randomness failure, which is the exact property that would have contained both this incident and Coldcard's.

And treat wallet software the way you would treat a custodian: an app that has left the app store, lost its maintainer, or stopped shipping updates is not a neutral tool aging gracefully. It is an unattended surface holding your private keys, and it deserves a planned migration, not sentiment.

What to Watch

The confirmed-app list is the number to track: Coinspect could not examine wallets already delisted, so 5 names are a floor, and new confirmations would retroactively expand the exposed population. On-chain data will show whether the identified-but-unswept portion of the 2,114 vulnerable wallets gets drained now that the advisory is public; a post-disclosure acceleration would confirm the advisory-as-map dynamic this series keeps documenting.

Watch whether uses of the same function outside seed generation (session tokens, API keys, one-time codes in software far from crypto) produce a second wave of disclosures, since CryptoJS ships in far more than wallets. And watch whether any wallet vendor answers with the obvious product response: entropy attestation a user can verify at generation time.

Tracked entities this report names, with total coverage across the archive. Follow one into the Actor Network to see every report it appears in.

Other reports that name the same tracked actors — a different thread than “related,” which follows wording. These are linked by who appears in them.