Ill Bloom is a $3.1M lesson in weak randomness, again

Argentine security firm Coinspect has disclosed a weak-randomness flaw in the way some mobile cryptocurrency wallets generate their recovery phrases. The firm is calling it Ill Bloom, and it has stood up a checker at illbloom.org so people can look up whether one of their addresses is in the exposed set without waiting for their wallet vendor to say something. Attackers ran a coordinated sweep on 2026-05-27, draining roughly $3.1 million from 431 addresses; another ~$2 million has moved out of exposed wallets since. Bitcoin took the worst of it at about $2.57 million, with a single BTC address losing more than $1.1 million. There is no CVE and, at time of writing, no named vendor.

Analysis, not incident reporting. The exploitation is confirmed and sourced; the framing below is commentary on a pattern the disclosure fits into, not a technical review of Coinspect’s research.

What the flaw is, without teaching it

The affected wallets generated their recovery phrases — the twelve or twenty-four words that stand in for the private key — from a random-number generator that was not random enough. In Coinspect’s phrasing, the pool of possible phrases shrank from astronomically large to a range an attacker could search. Once that search is feasible, whoever runs it first controls every wallet in the reduced pool. The affected chains include Bitcoin, Ethereum, Rootstock, Tron, and Polygon; the address checker at illbloom.org lists more.

Coinspect has not named the wallet apps. That is a deliberate choice, and a defensible one — publishing app names before the affected users have migrated would put the remaining balances on a target list — but it also means readers cannot check “am I safe” the way they usually would, by looking at the version they are running. The address-level checker is the substitute. Hardware wallets are described as unaffected. The specific seeding mechanism, the affected library, and the disclosure timeline have not been published yet.

The industry has been here before

Weak randomness in cryptographic key generation is one of the oldest mistakes the field has, and it has been rediscovered in a new substrate about every ten years since the mid-nineties.

In 1995 Ian Goldberg and David Wagner reverse-engineered Netscape’s SSL implementation and found the browser was seeding its session-key PRNG from the process ID, the parent process ID, and the time of day. A workstation on the same network could enumerate all three cheaply, and did. Netscape shipped a fix within days and the incident became one of the founding parables of the open-review argument for security software.

In 2006 the Debian project introduced a one-line change to its OpenSSL package that removed uninitialized-memory reads from the PRNG seeding path. The change silenced a Valgrind warning and made the resulting keyspace almost small enough to enumerate on a laptop. The bug shipped in Debian and its derivatives for almost two years before Luciano Bello found it in 2008; every SSH key, every OpenSSL-generated TLS key, every OpenVPN key produced on an affected system for that period had to be regenerated. The revocation list ran for years.

The pattern in both cases is the same. A cryptographic primitive that depends on unguessable inputs was fed guessable ones. The consumers of the primitive — browsers, servers, sysadmins — could not tell by looking, and had no reason to. The mistake was in the plumbing, invisible until someone audited the plumbing. Ill Bloom is the same mistake in a new substrate: mobile BIP39 seed generation, in an ecosystem where the “vendor security response team” for a lot of the affected code is one developer with a day job and no PSIRT.

What is different this time

Two things are unusual about the disclosure shape, and both are downstream of the substrate.

The first is that there is no coordinated vendor release. In the Netscape case, Netscape shipped the fix; in the Debian case, Debian did. Ill Bloom does not have that single point of remediation, because the affected code is scattered across a mobile-wallet ecosystem that does not have a standing coordination body. Coinspect’s decision to publish through an address checker instead of an advisory list is a workaround for that absence, not a preference for it.

The second is that the remediation is not “update to a fixed version” but “generate a new seed and move your funds.” A cryptographic key that was produced from bad randomness cannot be patched. The best a wallet update can offer is a fresh seed produced from good randomness — and the old balance, once the fresh seed is in place, has to be moved out from under the old address before an attacker gets there. That is a user action, not a vendor action, which is the part of the disclosure that will decide how much of the $2 million-and-counting outflow continues.

What to do

If you hold significant balances in a mobile wallet, especially one that predates 2020 or one from an outfit without a documented security response process, check your addresses at illbloom.org. If any of them match: create a new wallet with a new recovery phrase — from a wallet whose entropy source you can name, ideally a hardware wallet — and move the funds. Do not reuse the exposed phrase anywhere. If you distribute a wallet application yourself, this is the week to audit your seed- generation path against a documented CSPRNG and publish what you found.

The rest of the writeup will land when Coinspect publishes affected vendors and versions. Until then, the useful thing readers can do is treat the address checker as authoritative and act on it. This is one of those disclosures whose value is not in the framing but in the outbound throughput of migrated wallets, and that number is being written right now, one recovery phrase at a time.

---

Related coverage on 0dayNews:

• Injective SDK 1.20.21 on npm shipped a wallet stealer — a different route to the same target.
• GitHub ‘Verified’ commits can be rewritten without breaking signatures — another cryptographic label that turned out to mean less than users assumed.
• The clearinghouse boom is not new, and neither is the fatigue — same-decade, same-mistake framing in a different corner of the field.