Ill Bloom: The Wallet Bug That's Already Cost Victims $5 Million

Executive Summary

Every self-custody crypto wallet is protected by a recovery phrase — the 12 or 24 words that control the money. Those words are supposed to be chosen at random from a pool so enormous that guessing them is effectively impossible. Ill Bloom is what happens when the randomness fails.

The blockchain security firm Coinspect discovered that certain wallet software used a broken pseudo-random number generator (PRNG) when it created recovery phrases. Instead of drawing from an astronomically large pool of possibilities, the affected software drew from a range small enough that an attacker who understands the flaw can reconstruct the phrase — and with it, the private keys and the funds.

The problem is not theoretical. On-chain evidence confirms an active attacker draining these wallets, and the on-chain record now shows two coordinated drain waves: a first sweep on May 27, 2026 that took roughly $3.1 million from 431 wallets, and a second wave running from late May through mid-July 2026 that took roughly $2.55 million more — including a single ~$2.185 million stablecoin drain on July 4. Because the flaw was reused across different wallet projects, one weak recovery phrase can expose funds on different chains it controls. Coinspect has now traced exposed activity across Bitcoin, Ethereum, Tron, Polygon, and Rootstock.

A few points matter for readers deciding whether they need to worry:

Most people are fine. Hardware wallets and most mainstream software wallets are not affected. The affected Bitcoin addresses observed so far cluster in a roughly 2018–2022 window, pointing to older or lesser-known software wallets — though newer wallets may also be affected and the vulnerable software may still be in use, so it is worth checking regardless of a wallet's age.
This is not over. The first wave left most balances untouched; the second wave came back for them. More than $5 million has now left exposed wallets, and these totals are described as a floor,not a ceiling.
The only real test is to check. Coinspect has published a free wallet checker at illbloom.org. If your address matches, treat the recovery phrase as compromised and move your funds to a brand-new wallet.

This is not a new class of failure. It is the same trap that produced Milk Sad, the Trust Wallet browser-extension bug, and Randstorm in years past. Weak randomness gets baked into a wallet at the moment of creation, lies dormant for years, and is then harvested all at once. The wallet looks fine. The words look random. But the machine that picked them was predictable — and a predictable key is barely a key at all.

What Actually Broke

Ill Bloom takes its name from "illness blossom," the first weak recovery phrase produced by the flawed generator. Like Milk Sad before it, the vulnerability is named after the first recognizable phrase emitted by the broken algorithm.

The root cause is a broken PRNG used during recovery phrase generation. A correct implementation seeds phrase creation with high-quality entropy so that the resulting seed is drawn from a space of 2^128 or 2^256 possibilities. The affected software instead produced phrases derived from significantly reduced effective entropy, collapsing that space to a range an attacker can exhaustively search.

The attack was reproduced end to end, and the methodology is what makes this research credible rather than speculative:

Identify the root cause — the specific broken PRNG behavior.
Model the reduced-entropy seed space the vulnerable generator can produce.
Derive the wallet addresses each of those seeds leads to, across chains.
Cross-reference against public blockchain data to find which of those addresses are actually funded.

Critically, while the investigation began in response to a wallet-drain incident, this analysis did not start from suspicious on-chain activity. Coinspect independently reconstructed the vulnerable seeds and addresses first, then went looking for them on-chain. The output is a watchlist called the Ill Bloom Exposed Address Set — a list of wallets that were, in effect, born weak, regardless of which app generated them. The set continues to grow as more seeds are derived; at the time of the Bitcoin analysis it contained over 12,000 Bitcoin addresses alone.

The PRNG itself is old. Its reach is not. The vulnerable code appears to have been imported and reused across multiple wallet projects and networks over the years. That single structural fact — code reuse — is what gives Ill Bloom a multi-chain blast radius far larger than any single-app incident. Because the same seed material derives keys on multiple chains, one compromised recovery phrase can expose assets everywhere at once.

The exact size of the seed space has not been published and the affected libraries or apps have not been named yet — deliberately, to avoid handing uplift to other attackers while funds remain exposed.

How the Disclosure Unfolded

Ill Bloom has been handled through a staged (coordinated) disclosure process. As a trusted threat-intelligence partner in Coinspect's disclosure, Crypto ISAC received strategic, non-public information at each stage — including the underlying research and the set of at-risk wallets — ahead of any public release, and passed it directly to its members. That privileged early access is one of the tangible benefits of membership: while the vulnerability was still confidential, members were able to receive the exposed-wallet intelligence, cross-reference it against their own user bases, and act on it before the wider market knew Ill Bloom existed. The timeline matters, because each stage added materially new facts — and because the attacker kept moving throughout.

May 21–23, 2026 — Attacker preparation (established later). On-chain evidence would later show the attacker already co-spending outputs from multiple exposed addresses days before the first mass drain.
May 27, 2026 — The first drain. A single automated operation swept funds from hundreds of exposed wallets across Bitcoin and Ethereum on the same day. This is the first confirmed exploitation; earlier activity is suspected but unconfirmed.
June 10, 2026 — First public signal. Coinspect flags Ill Bloom publicly through its own channels, putting an early warning in front of the broader community ahead of the coordinated disclosure.
June 25, 2026 — Crypto ISAC's first member alert. Established the vulnerability, confirmed active on-chain exploitation, flagged the multi-network footprint from code reuse, and shared the first on-chain indicator. At that stage, confirmed evidence was limited to a single at-risk wallet and an attacker observed operating across chains.
June 30, 2026 — Coinspect's first Bitcoin working notes. A detailed forensic reconstruction of the May 27 Bitcoin activity. As of this analysis, most of the drained Bitcoin was still parked, unspent, at the attacker's destinations — an open recovery window.
July 1, 2026 — Crypto ISAC's second member alert. Quantified the first drain, documented the attacker's operational pattern, shared the attacker indicators and access to the at-risk wallet set so members could screen their own platforms, and added Crypto ISAC's own analysis of victim address types — a scoping contribution not present in Coinspect's notes. All of this reached members while the technical details were still confidential and days before public disclosure.
Early July 2026 — The second wave begins in earnest. The wallets left untouched in May started emptying. On July 4, a single exposed account holding roughly $2.185 million in stablecoins on Tron was drained — the largest single loss of the entire incident to date.
July 10, 2026 — Public disclosure, and a second mass drain the same day. Coinspect went public and opened the illbloom.org checker to everyone. On that very day, the attacker executed a coordinated multi-chain sweep — Bitcoin, Ethereum, Polygon, and Tron activity all confirmed on July 10.
July 13, 2026 — Coinspect's second working notes. A forensic reconstruction of this second drain event, documenting roughly $2.55 million removed across five chains between May 30 and July 13, and a notable shift in the attacker's laundering behavior (below).

The First Drain — May 27, 2026

Coinspect's first Bitcoin working notes document the May 27 activity in forensic detail. On that day, 220 Bitcoin addresses from the Exposed Address Set sent 33.72 BTC — about $2.57 million at the prevailing price — to more than 200 destination addresses. There was exactly one drain transaction per victim address, and each went to a fresh, effectively unique destination — a deliberately inconspicuous pattern, since a fan-out to hundreds of new addresses attracts far less attention than a single large sweep.

Internal labeling splits each derived address into either "Wallet 1" or "Other." Value was heavily concentrated: the top eight drains accounted for roughly 92% of all value drained, with a single Bitcoin address losing over $1.1 million on its own. The many smaller drains were individually tiny — often under $1,000.

The signature of automation

The distribution of the drain transactions across blocks is the clearest fingerprint of an automated attack rather than hundreds of coincidental owners acting at once:

162 of the 220 drain transactions confirmed in a single block; 217 of 220 confirmed across four blocks within roughly three and a half hours. Hundreds of independent, long-dormant wallet owners do not spontaneously move funds within the same block. This is batch execution.

Preparation, days in advance

Before the drain, from May 21 through May 23, single Bitcoin transactions were already co-spending outputs from multiple exposed addresses. When one transaction spends outputs from multiple addresses, the signer must hold all the corresponding keys — and one of these pre-drain transactions merged 29 exposed addresses, spanning both of Coinspect's internal address-set labels, into a single transaction. The attacker had assembled and validated access at least six days ahead of the sweep. This was systematic preparation, not opportunism.

The funds stayed put — at first

Three days later, on May 30, a single transaction spent dozens of the drain destinations into one collector address, proving that one party controlled at least 85 of those destination keys simultaneously. Tellingly, that consolidation moved only a trivial amount of dust — the large drains were left exactly where they landed.

Late-June analysis identifies roughly 87% of the drained Bitcoin (about 29.48 BTC) remained unspent at its initial destination, including every one of the large drains. That created a genuine, time-sensitive opportunity: while these destinations can be tracked and flagged if the funds ever reach a regulated venue, self-custodial balances can't be frozen at the source by anyone but the keyholder. As the following sections show, that reprieve did not last.

Cross-Chain Confirmation

The same operator was active on Ethereum on the very same day. Coinspect's cross-chain analysis identified an Ethereum-side collector — one that was flagged as a known wallet drainer on Etherscan — receiving funds from 174 accounts on May 27. The co-occurrence of Bitcoin and Ethereum drain activity on the same date, combined with the shared address-set linkage seen in the pre-drain co-spending, supports the conclusion that a single operator executed the cross-chain drain simultaneously. Coinspect is careful here: this is an inference from multiple facts pointing in the same direction, not proof of who controlled the destination addresses.

By June 30, Coinspect had traced over 2,100 exposed addresses with on-chain activity across five networks — Bitcoin, Ethereum, Tron, Polygon, and Rootstock. At its 2022 peak, that address set held a reconstructed $12.56 million, though much of that value had already fallen with the market before the drains began.

Why the assessment is "attacker drains," not "owners fleeing"

One benign explanation is that owners or white-hat responders were moving at-risk coins to safety. The on-chain facts favor attacker drains for several reasons:

Protective-transfer activity in the dataset appears only after May 28 — the May 27 drains predate it.
Cross-chain analysis found malicious patterns on the same date, funneling to the Etherscan-flagged drainer.
The block pattern indicates automation (162 transactions in one block).
Destinations are fresh per-victim addresses with no prior history — not known owner addresses or an announced recovery collector.
Addresses from both internal labels were spent together before the drain, and dozens of destinations were spent together after it.
The victims are long-dormant addresses.

Crypto ISAC Analysis: What Victim Address Types Reveal About the Wallet Generation Era

The following is Crypto ISAC's own analysis, derived from the victim address data in Coinspect's Bitcoin working notes. It is offered as additional scoping context and is inferential — suggestive, not conclusive.

Coinspect's forensics tell us when the drain happened, how long the victim addresses had been dormant, and that they belong to the Exposed Address Set. Crypto ISAC took one further step: we examined the Bitcoin address formats of the victims, because the type of address a wallet generates by default is a strong tell about the software era in which it was created.

Address type distribution among drained victims

Examining the victim addresses from the eight largest drain transactions — roughly 92% of total drained value — reveals a spread across three distinct Bitcoin address types:

P2PKH (Legacy, addresses beginning with "1"): six of the eight largest-value victims.
P2SH (addresses beginning with "3"): one of the eight. P2SH can encapsulate several script types, including wrapped SegWit and multisig; the subtype cannot be determined from the address format alone.
P2WPKH (Native SegWit, bech32 addresses beginning with "bc1q"): one of the eight.

What address types suggest about the wallet generation era

The default address type a Bitcoin wallet generates is largely determined by the software version and era of creation:

P2PKH was the universal standard before roughly 2017–2018, when SegWit adoption began.
P2SH-wrapped SegWit became common from roughly 2017 onward.
Native SegWit (bech32) became more widely available from roughly 2018–2019 onward, with adoption varying significantly by wallet.

The dominance of P2PKH among the highest-value victims is consistent with wallets created before SegWit was widely adopted — aligning with Coinspect's finding that affected accounts are old. But the presence of P2SH and native SegWit addresses in the victim set suggests the affected software may have continued generating vulnerable wallets into a later period, or that some wallet software moved to newer address formats while retaining the same flawed PRNG.

The dormancy data corroborates this. All 220 drained addresses had prior on-chain history, and the gap between their last activity and the May 27 drain was substantial:

A median dormancy of ~4.3 years as of May 2026 places typical wallet creation around 2020–2022, while the longest-dormant addresses point back to roughly 2018–2019. One legacy wallet, for example, was funded in September 2021 and sat untouched for about 4.7 years until the drain. The simultaneous movement of wallets idle for years, in a single automated sweep, is among the strongest behavioral indicators separating attacker drains from any benign explanation.

What address-type diversity may suggest about software lineage

Coinspect's two internal labels both appear in the pre-drain co-spending transactions, indicating one attacker controlling addresses from both groups. The presence of multiple Bitcoin address types among the victims is consistent with — though not proof of — more than one distinct wallet codebase being involved, each defaulting to a different address format at creation while sharing the same underlying vulnerable PRNG through code reuse. This is exactly what the "imported and reused across projects" theory predicts.

Implications for scoping your own exposure

These are preliminary, non-exhaustive indicators — none of them individually diagnostic:

Wallets generated roughly 2018–2022 are most consistent with the observed dormancy and address-type profile.
Legacy P2PKH is the most common format among high-value victims and is consistent with older wallet defaults — but it is not exclusively associated with Ill Bloom.
The presence of P2SH and native SegWit victims means scope is not strictly limited to the oldest era; do not exclude accounts with newer address formats from review. (As the second drain would later confirm, even Taproot-era addresses appear in the exposed set.)
Address type and creation era are suggestive, not confirmatory. The authoritative test for an affected address remains membership in the Coinspect Ill Bloom Exposed Address Set.

The Second Drain — Late May Through July 13

The May 27 sweep, for all its scale, left most of the exposed value untouched. The obvious question was whether the attacker would come back for it. Coinspect's July 13 working notes answer it: yes.

Between May 30 and July 13, the attacker systematically emptied exposed wallets that had still held a balance after the first drain — a population defined from a June 22 snapshot. Across Bitcoin, Ethereum, Tron, Polygon, and Rootstock, roughly $2.55 million more was drained. The single largest loss of the entire incident falls in this window: on July 4, one exposed Tron account holding about 2,185,000 USDT (~$2.185 million) was emptied — by itself, roughly 87% of the second event's value.

That Tron account is a revealing outlier. Every earlier victim fit the profile of an old, long-dormant wallet reactivating after years of silence. This one was actively in use right up to the drain — the first documented Ill Bloom victim that breaks the dormancy pattern, and a reminder that "old and forgotten" is a common trait of affected wallets, not a defining one.

A change in the attacker's playbook

The most analytically interesting shift is in how the funds moved. In May, each victim's Bitcoin went to its own unique destination — a fan-out designed to stay quiet. In this second event, the Bitcoin drains were consolidated into a small number of reused collector addresses: the overwhelming majority of the 88 Bitcoin drains flowed into just four collectors, and the largest of them gathered funds from dozens of distinct victims and still holds the full consolidated balance, unspent. On Ethereum, both drains went to a single shared collector. The same consolidation pattern — many unrelated victims funneling into a few destinations within hours — is precisely what led to the conclusion that a single party was in control.

The Bitcoin side of this second event again bore the automation signature: 86 of the 88 Bitcoin drains landed on July 10, in two waves (a morning batch and an evening batch), spread across 33 blocks in about 22 hours, with heavy clustering — over a dozen independent drain transactions confirming in a single block. The largest single Bitcoin drain in this event, worth roughly $206,000, went to a Taproot (bech32m) address — a wallet format newer than anything in the May victim set, and further evidence that the exposed population is not confined to the oldest era.

On the EVM chains, the drains came in three waves: an early cluster in late May/early June, a second concurrent with the July 10 Bitcoin activity, and — most tellingly — a July 12 sweep that emptied roughly 285 near-empty Ethereum wallets for a combined total of around a hundred dollars. Draining hundreds of wallets that each hold pennies makes no economic sense for an opportunist; it makes perfect sense for an automated process working methodically through a known list.

Dormancy, again

The 88 Bitcoin victims in this event had a median dormancy of about 800 days, lower than the first event's 4.3-year median — unsurprising, since these were the wallets still active enough to be holding balances in June. But most were still long-idle: nearly two-thirds had been dormant for at least a year, with the oldest untouched for over seven years. The pattern holds: dozens of long-silent wallets reactivating together, on a single day, in a single automated sweep.

Coinspect's assessment mirrors the first event: the July movements are most likely attacker drains — automation, consolidation into attacker-controlled collectors, dormant victims reactivating in lockstep, all drawn from the known Exposed Address Set, and now a second event following the same pattern as the first. As always, it is an inference from circumstantial evidence, not proof of who controlled the destinations.

The through-line across both events is stark. In May, the money was taken but left in place — an open window. Over the following six weeks, that window closed: the attacker returned, swept the remaining balances, and in the largest single stroke took more than $2 million from one wallet in one transaction.

We Have Seen This Before

Ill Bloom is an old failure with a new name. Every few years, a wallet's random-number generator turns out to be predictable, and wallets that looked safe become drainable:

Milk Sad (CVE-2023-39910, 2023): Weak entropy in the Libbitcoin Explorer command-line tool let thieves drain millions in a single July sweep. Ill Bloom's naming convention deliberately echoes it.
Trust Wallet browser extension (CVE-2023-31290, 2023): A close cousin — recovery phrases crackable in under a day.
Randstorm (2023 disclosure): Poor browser-based randomness left Bitcoin wallets created between 2011 and 2015 crackable years later.

The lesson repeats: weak randomness is baked into a wallet permanently at the moment of creation. No patch reaches back to fix a phrase that already exists. The only remedy is to generate a new phrase with sound software and move the funds. That was the fix for Randstorm and Milk Sad, and it is the fix for Ill Bloom.

As Coinspect put it: "if funds recently moved without your permission, this vulnerability may be why."

What To Do

For individuals:

Check every address tied to the same recovery phrase — not just the ones already drained — at illbloom.org. The checker accepts Bitcoin, Tron, Solana, and Ethereum-style (EVM) addresses. A clean result is not a guarantee (the list is incomplete), but a match is a clear warning.
If you match, treat the recovery phrase as compromised. The money is not safe just because it hasn't moved yet — as the second drain showed, balances left untouched in one wave were emptied in the next.
Create a brand-new wallet with a brand-new phrase — ideally on a hardware device, generating a fresh phrase on the device rather than importing the old one. If an app asks you to type your old phrase, you are reopening the weak wallet, not making a new one.
Move your funds to the new wallet. Reinstalling the old app or importing the same phrase elsewhere changes nothing.

Beware of "recovery" scams. A legitimate checker never needs a secret. Coinspect states it "will never ask for seed phrases, private keys, signatures, or approvals, or ask users to send funds to 'recover' or protect a wallet." Never type your recovery phrase, private key, password, or backup file into any site or message.

For exchanges, custodians, and security teams:

Watch for the dormancy anomaly — the simultaneous movement of large numbers of long-dormant wallets is a detectable pattern worth adding to detection coverage. It is the single most consistent signature across both drain events.
Track the attacker's consolidation points. Coinspect and Crypto ISAC maintain a set of indicators — attacker-controlled collector addresses across Bitcoin, Ethereum, and Tron, along with drain-destination lists — which can be ingested for monitoring, screening, and compliance so stolen funds can be flagged if they surface at a regulated venue. Several of these collectors still hold their consolidated balances unspent. (These indicators are being managed through the coordinated disclosure process; Crypto ISAC members can request the current set.)
Contribute library attribution data. If you can correlate affected addresses with the wallet software or SDK that generated them (via app-version telemetry, SDK attribution, or onboarding data), that intelligence is what identifies the vulnerable libraries and enables targeted vendor notification. Route it to Crypto ISAC.
Engage law enforcement through the right channel. Many of the highest-impact actions against this attacker — freezing consolidated balances at a counterparty, seizing funds, or attributing the operator — sit beyond what any single member can do alone and require law enforcement involvement. Crypto ISAC is positioned to enable that engagement in an optimal way: aggregating member observations into a coherent intelligence picture and routing it, alongside Coinspect's findings, to the appropriate law enforcement partners so that members' actions are coordinated rather than fragmented.
Consider targeted user communication for consumer-facing user bases who may have generated wallets on older software during the affected period.

To be clear on scope: these are self-custodial wallets, so the drain of an affected wallet is not something an exchange, custodian, or ISAC member could have blocked at the source — the attacker holds the reconstructed keys. Defender value lies in interdiction downstream, in warning users to migrate before they are hit, and in the shared intelligence that has driven this coordinated response. And where acting on the indicators requires more reach than a member holds on its own — a freeze, a seizure, a cross-jurisdiction request — that is precisely where law enforcement becomes necessary, and where Crypto ISAC can bridge its members to the right agencies quickly and with the full evidentiary picture already assembled.

Assessment

Ill Bloom is not a theoretical risk. An automated attacker drained hundreds of wallets across multiple chains, twice, in coordinated operations bracketed by days of visible preparation and methodical follow-up. The broader pattern is textbook: weak randomness introduced years ago, propagated silently through code reuse, now being systematically harvested by an attacker who characterized the flaw independently.

The attack surface is bounded by history. The attacker is operating in the present. The two-wave shape of this incident is its most important lesson. After May 27, most of the stolen Bitcoin sat untouched, and it was tempting to read that as a stalled or clumsy operation. It was neither. The balances that survived the first sweep were emptied in the second — culminating in a single multi-million-dollar stablecoin drain — and the exposed set continues to be worked through, chain by chain, wallet by wallet.

Closing this attack surface is a collective effort. Individuals check and migrate; platforms screen, warn users, and contribute attribution data; and where the response demands authority that no private party holds — freezing, seizing, or attributing across borders — law enforcement must be brought in. Crypto ISAC's role sits at that seam: turning privileged, non-public intelligence into action for its members, and channeling the combined picture to law enforcement so the ecosystem responds as one rather than in isolation.

If you generated a wallet on older or lesser-known software, the cost of checking is a minute. The on-chain evidence points to roughly 2018–2022, but newer wallets may be affected and the vulnerable software may still be in use — so age alone is not a safe assumption. The cost of not checking could be everything the phrase controls — and, as the past six weeks have shown, waiting does not make the funds any safer.

This post synthesizes Crypto ISAC member alerts (June 25 and July 1, 2026), Coinspect's Bitcoin incident working notes (June 30 and July 13, 2026), and public reporting. Specific indicators of compromise have been withheld pending completion of the coordinated disclosure process. The victim address-type analysis is Crypto ISAC's own contribution and is inferential. On-chain conclusions about attacker control rest on circumstantial evidence, as noted throughout.

About the Author:

Tiago Assumpcao is the Technical Director of Threat Intelligence Engineering at Crypto ISAC. With over 25 years in cybersecurity, his career demonstrates a clear trajectory: from pioneering exploit defenses in the early 2000s to shaping the security posture of today’s crypto ecosystem. He has contributed to foundational memory protection mechanisms, served as an editor at Phrack, and led security initiatives at BlackBerry, IOActive, and Coinspect. His work spans from pioneering exploit defenses to securing digital asset ecosystems against systemic risks and nation-state threats. He recently participated as a panelist at Upbit D Conference and DeFi Security Summit.

About Crypto ISAC

The Crypto ISAC is a member-driven, not-for-profit organization that works together to curb malicious actors, address vulnerabilities, share intelligence, and move security forward to protect the crypto ecosystem. We are founded by leading crypto organizations and designed for cryptosecurity experts to address the security and trust challenges that face crypto today and shape the crypto ecosystem of tomorrow.