Your Recovery Phrase Was Never Random. 'Ill Bloom' Drained $5M by Guessing Seeds That Should Have Been Unguessable. You Can't Patch This One — You Have to Abandon the Wallet.
- Patrick Duggan
- 3 hours ago
- 4 min read
Almost every crypto theft we write about is an operational failure: someone got phished, cloned a webshell, installed a malicious wallet extension, approved a transaction they shouldn't have. Ill Bloom is not that. Ill Bloom is a story about mathematics, and it is the scariest kind, because the victims did nothing wrong. They generated a wallet, wrote down the twelve or twenty-four words, and stored them properly. The problem is that the words were never random in the first place — and a private key that was never random was never really yours.
What happened
On July 6, Coinspect Security Research disclosed Ill Bloom, a vulnerability rooted in how some wallets generate their recovery phrases. A seed phrase is supposed to be born from true randomness — enough entropy that the number of possible phrases is astronomically large, so large that no attacker could ever guess or brute-force yours. That guarantee is the entire security model of self-custody. Ill Bloom breaks it at the source: the affected wallets used defective random number generators, so their seed phrases were drawn from a keyspace far smaller than it should have been. The phrases were mathematically predictable. And once a keyspace is small enough to search, an attacker doesn't need your words — they can generate the candidates themselves, check each one against the blockchain, and sweep any address that holds a balance.
That is exactly what happened. The analysis identified 2,114 affected addresses across Bitcoin, Ethereum, Tron, Rootstock, and Polygon. On May 27, attackers drained 431 of them for about $3.14 million, and the total losses now sit around $5 million. This wasn't theoretical for six weeks before disclosure — the money was already gone.
Why this is the oldest nightmare in cryptography
If you have been around security long enough, Ill Bloom will give you a specific chill, because we have seen this exact failure before. In 2008, a well-meaning change to Debian's OpenSSL package gutted the entropy in its random number generator, and for two years every SSH and SSL key generated on those systems was drawn from a tiny, enumerable set. Attackers didn't have to break the cryptography — the cryptography was fine. They just had to precompute the handful of keys that were actually possible. Ill Bloom is that same disaster wearing a crypto-wallet costume: the algorithm was sound, the randomness feeding it was not, and weak randomness is indistinguishable from no security at all.
This is the difference worth internalizing. We have covered plenty of crypto-wallet threats on this blog — the Pattern 49 phishing kits on Cloudflare and GitHub Pages, the npm packages that steal seed phrases, the malicious extensions. Every one of those is an attack on the user. Ill Bloom is an attack that required no interaction with the user at all. There was no click, no malware, no mistake. The wallet handed out doomed keys the moment it was installed, and the only "vulnerability" the victim had was trusting that the dice were fair.
Who is actually at risk (and who isn't)
Do not panic-migrate if you don't have to. The evidence is fairly clear on scope:
Hardware wallets are not affected. Their entropy comes from dedicated, audited hardware sources — this is precisely the disaster they exist to prevent.
Most current mainstream software wallets are not affected. The well-known, widely-audited wallets use the operating system's cryptographic RNG, which is sound.
The strongest candidates are less widely-used mobile software wallets — the kind that rolled their own randomness or leaned on a weak platform source, and never got the scrutiny a popular wallet gets.
So the risk concentrates exactly where you'd expect: the obscure, the unaudited, the "I found this wallet app and it looked fine."
What to do
Here is the part that makes Ill Bloom uniquely nasty: you cannot patch it. A software update can fix the RNG going forward, but it cannot un-compromise a seed that was already generated from bad randomness. If your keys came out of a weak generator, those keys are enumerable forever, and no amount of updating changes the words you already wrote down.
The only real remediation is the drastic one: generate a brand-new wallet from a trustworthy source — a hardware wallet or a major, audited software wallet — and migrate every asset to addresses derived from that new seed. Then retire the old wallet completely. If you hold anything meaningful in a lesser-known mobile wallet and cannot confirm it is unaffected, treat that seed as burned and move the funds. Moving costs you a transaction fee. Waiting could cost you everything, and the attackers already have a six-week head start.
Held to about ninety-five percent — the affected-wallet list is still being refined, and if you use a hardware or mainstream wallet you are very likely fine. The disclosure and the on-chain analysis are Coinspect Security Research's, and it is careful, important work. What we add is the framing security people need to hear: this was not a hack of your wallet. It was a hack of the randomness underneath it — the oldest way in the book — and the lesson, from Debian in 2008 to your phone in 2026, never changes. When the entropy is weak, the keys were never secret. They were just waiting to be counted.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Comments