Ill Bloom Wallet-Generation Vulnerability: What Happened, Who Is Affected, and What Users Should Do
The Ill Bloom wallet vulnerability is a wallet-generation failure, not a conventional phishing attack, malicious approval, or smart-contract exploit. Certain software wallets generated recovery phrases using a weak randomness implementation inherited through CryptoJS. Those phrases looked like ordinary BIP39 recovery phrases and produced normal blockchain addresses, but the effective randomness behind them was dramatically smaller than users expected. That allowed attackers to enumerate candidate phrases offline, derive corresponding wallet addresses, identify funded accounts on public blockchains, and drain assets without ever needing the victim to click a malicious link or reveal the phrase.
TL;DR
- Ill Bloom is a recovery-phrase generation vulnerability now tracked as CVE-2026-71851.
- The underlying problem was a weak pseudorandom number generator used by vulnerable versions of CryptoJS through CryptoJS.lib.WordArray.random().
- The affected generator could produce recovery phrases with far less effective entropy than the nominal 128-bit or 256-bit security level suggested by the phrase format.
- Researchers estimated effective search spaces of roughly 2^39 possibilities for nominal 128-bit entropy and roughly 2^47 for nominal 256-bit entropy under the vulnerable generation path.
- The recovery phrases still looked normal. They used valid BIP39 words, checksum rules, derivation paths, and ordinary blockchain addresses. Visual inspection could not reveal the weakness.
- The currently confirmed affected applications are RRWallet, Bexo Wallet, NanChat, Bitcoin Libre, and Milo. Researchers explicitly warn that this list may not be exhaustive.
- Bexo Wallet, NanChat, and Bitcoin Libre have identified fixed versions. RRWallet and Milo are discontinued.
- A software update does not repair a recovery phrase that was generated with weak randomness. The vulnerability is embedded in the original secret itself.
- Importing an affected seed phrase into MetaMask, Phantom, Ledger, another hardware wallet, or any other wallet does not create new entropy. The same underlying private keys remain recoverable by anyone able to reconstruct the seed.
- The correct migration is to create an entirely new recovery phrase using a trustworthy cryptographically secure generator, then move assets from every relevant account derived from the old seed.
- Do not type a recovery phrase into an online vulnerability checker. Legitimate exposure checks should require only public addresses.
- TokenToolHub's Wallet Risk Scanner and Solana Wallet Risk Scanner can help investigate public on-chain behavior, counterparties, approvals, assets, and suspicious activity, but they cannot determine whether a private recovery phrase had weak entropy when it was created.
- The first confirmed Ill Bloom drain wave identified by researchers occurred on May 27, 2026. Additional coordinated drains followed.
- Measured losses across two documented drain waves reached approximately $5.69 million, and the researchers describe this as a lower bound within their monitored dataset rather than a complete estimate of every potentially exposed wallet.
- The wider lesson is fundamental: a correctly formatted seed phrase is not necessarily a securely generated seed phrase.
If a recovery phrase was generated through an affected randomness path, treat the original recovery phrase as the security problem. Updating the application, changing a password, reinstalling the wallet, importing the same words into another wallet, or creating another account under the same recovery phrase does not replace the compromised entropy.
What happened in the Ill Bloom wallet vulnerability?
Every self-custody cryptocurrency wallet ultimately depends on secrets that attackers should not be able to guess. For many wallets, those secrets originate from a BIP39 recovery phrase, usually twelve or twenty-four words.
Those words are not supposed to be selected like a human password. Wallet software begins with cryptographically secure random entropy and transforms that entropy into a standardized sequence of dictionary words with checksum information. The words exist mainly because people can back them up more reliably than a long hexadecimal private key.
The security still comes from the unpredictability of the original random value.
Ill Bloom occurred because several wallet applications used a vulnerable randomness implementation when generating that value. The resulting recovery phrases complied with the expected format and could be imported into normal wallet software. The addresses and private keys derived from them behaved exactly like any other blockchain account.
The problem was that the seed-generation process had explored a much smaller universe of possibilities than the user believed.
An attacker who understands the weak generator does not need to guess from every theoretically possible twelve-word phrase. The attacker can recreate the restricted set of phrases the flawed algorithm could realistically produce, derive wallet addresses from those candidates, and compare them against public blockchain activity.
Once a candidate phrase produces a funded address that exists on-chain, the attacker can derive the same private key as the legitimate owner.
At that point there is no cryptographic distinction between attacker and victim. Both possess valid signing authority.
This was not a blockchain cryptography failure
Bitcoin's elliptic-curve cryptography did not need to be broken. Ethereum's signatures did not need to be cracked. Solana did not need to suffer a consensus failure. The attacker did not need to reverse SHA-256 or compromise the BIP39 standard.
The failure happened before those systems were used: the wallet generated the secret from inadequate randomness.
This distinction is important because users often assume a valid twelve-word phrase automatically has the security of all possible twelve-word BIP39 phrases. That assumption is true only when the underlying entropy was generated securely.
CVE-2026-71851 and the CryptoJS dependency chain
The root issue is now tracked as CVE-2026-71851. The affected function was CryptoJS.lib.WordArray.random() in vulnerable versions of the CryptoJS JavaScript cryptography library.
CryptoJS has historically been used for hashing, encryption, key derivation, and related cryptographic operations in JavaScript applications. The library itself was not designed solely for cryptocurrency wallets, and merely finding an old CryptoJS package somewhere inside an application's dependency tree does not prove a wallet generated vulnerable seeds.
The dangerous condition occurs when an application actually uses the vulnerable random function as its source of security-sensitive entropy.
Why the implementation was unsafe
The vulnerable implementation used a custom variation of a Multiply-With-Carry pseudorandom number generator seeded from JavaScript randomness rather than a proper cryptographically secure random source provided by the operating environment.
A general pseudorandom number generator can produce output that looks noisy and random to a human while still being predictable enough for an attacker with knowledge of its internal structure.
Cryptographic random generation has a stronger requirement. Even if an attacker knows exactly how the generator works, the attacker should not be able to reconstruct its secret state or enumerate a practically useful portion of its output.
How the vulnerable implementation reached wallet software
The important story is not simply CryptoJS is vulnerable. It is the dependency chain.
Researchers documented one path through a React Native oriented fork of a BIP39 library. The upstream BIP39 implementation relied on a package that delegated random generation to secure platform APIs such as Node.js cryptographic randomness or the browser's cryptographically secure random interface.
A downstream fork replaced that dependency with CryptoJS to provide a pure-JavaScript implementation that worked more easily across React Native environments.
That portability decision silently changed the wallet's security boundary. Code responsible for generating one of the most sensitive secrets in cryptocurrency was now relying on a generator whose output space was much smaller than expected.
Why dependency audits must follow data flow, not package names
A security review that only searches for vulnerable package versions can produce both false positives and false negatives.
An application might contain a vulnerable CryptoJS version but use it only for hashing data, in which case the Ill Bloom seed-generation path may not apply. Another wallet might hide the vulnerable randomness behind several wrapper libraries, making the dangerous call difficult to notice from a top-level dependency list.
The meaningful question is: what exact function produced the entropy from which the recovery phrase was generated?
Why weak randomness can create a valid-looking but unsafe recovery phrase
BIP39 does not judge whether your random source was good. It defines how entropy is converted into mnemonic words and how those words are transformed into a seed.
For a standard twelve-word recovery phrase, wallet software normally begins with 128 bits of entropy. A checksum is added, and the combined bits are divided into eleven-bit groups that map into a 2,048-word list.
A twenty-four-word phrase normally begins with 256 bits of entropy.
Both parts matter. A phrase can satisfy all BIP39 formatting rules while having come from a dangerously predictable generator.
What 128 bits should mean
A properly generated 128-bit secret has 2^128 possible entropy values. That is approximately 340 undecillion possibilities, far outside feasible brute-force enumeration with current computing technology.
The security assumption is not that an attacker cannot calculate fast enough today only because software is inconvenient. It is that the search space is astronomically large.
What happened under the vulnerable generator
Coinspect's technical disclosure found that nominal requests for 128-bit and 256-bit entropy through the vulnerable generation path had effective search spaces of approximately 2^39 and 2^47 possibilities respectively.
2^39 is roughly 550 billion possibilities. 2^47 is roughly 141 trillion.
Those numbers are still large from a human perspective, but cryptographic security is not measured against human guessing. Modern processors, GPUs, optimized derivation software, distributed computing, and filtering against public blockchain datasets can radically change what is practical when the search space collapses by dozens or hundreds of bits.
The words themselves do not expose the weakness
A vulnerable phrase does not necessarily contain obvious repetitions. It does not display a warning. It does not use invalid BIP39 vocabulary. It can look as random as any securely generated phrase.
That is why users cannot reliably inspect a recovery phrase and determine whether it is affected.
Security depends on the history of how the phrase was generated, not how random the words look afterward.
How weak wallet randomness becomes an on-chain drain
The Ill Bloom attack path is best understood as a supply-chain and secret-generation failure that becomes exploitable through the transparency of public blockchains.
User creates a wallet
The application is expected to obtain cryptographically secure random entropy for a new recovery phrase.
Weak dependency generates entropy
The vulnerable CryptoJS path produces output from a dramatically smaller effective search space.
Recovery phrase looks normal
BIP39 words and checksum remain valid, so the owner has no visual indication that the secret is weak.
Normal addresses are derived
The same weak phrase can generate ordinary accounts across Bitcoin, EVM networks, Solana, Tron, and other derivation paths.
Attacker searches offline
The attacker enumerates candidates produced by the vulnerable generation process rather than searching the full BIP39 universe.
Public addresses reveal matches
Derived candidates can be compared against public blockchain activity to find seeds associated with funded accounts.
Funds can be drained
Once the seed is reconstructed, the attacker derives legitimate private keys and can sign transactions without victim interaction.
How long did the CryptoJS weakness exist?
The vulnerable randomness logic has a long history, which helps explain why discovering every downstream application is difficult.
The weak Multiply-With-Carry based implementation was introduced into CryptoJS during 2014. Researchers identified it beginning with the 3.1.2-4 release line.
There was a temporary period in the 3.x branch where platform-native cryptographic randomness replaced the vulnerable implementation. Versions 3.2.0 and 3.2.1 are notable exceptions in the historical sequence described by the researchers.
The change was later reverted in CryptoJS 3.3.0 because the platform-dependent approach was considered a compatibility-breaking change.
A cryptographically secure platform-native random source returned in CryptoJS 4.0.0 in February 2020.
An application is exposed to Ill Bloom only when the vulnerable randomness implementation was actually used to generate security-sensitive wallet entropy. CryptoJS may appear in software for unrelated hashing or encryption operations without having generated the recovery phrase.
Which wallets have been confirmed affected?
Coinspect's investigation currently names five confirmed applications: RRWallet, Bexo Wallet, NanChat, Bitcoin Libre, and Milo.
The researchers explicitly state that this is not necessarily the complete universe of affected applications. Some wallets are closed source, some have been discontinued, historical application packages may be difficult to locate, and a public blockchain address does not reveal which software originally generated its recovery phrase.
| Wallet | Status | Published remediation status | What users should understand |
|---|---|---|---|
| RRWallet / RenrenBit | Discontinued | No current fix available for the discontinued software | A recovery phrase originally generated through the vulnerable path should be treated as a historical secret that may remain exposed even if the application is no longer installed. |
| Bexo Wallet | Active | Researchers identify version 20.1.0 as the fixed version | Installing a fixed release prevents reliance on the old generation path for new wallets, but it does not regenerate an existing weak phrase. |
| NanChat | Active | Fixed in version 1.3.0 | Historical phrases created using vulnerable versions require migration. An application update alone cannot add entropy to the old phrase. |
| Bitcoin Libre | Active | Fixed in version 4 | Researchers found that some historical versions before version 4 used the vulnerable generation path. Wallet creation history matters. |
| Milo | Discontinued | No current fix available for the discontinued software | Users should not rely on application availability as evidence that the original seed remains secure. |
The wallet name alone is not always enough
An active application's current version can be safe while an older phrase created years earlier remains weak.
The key question is not only which wallet app do I use today. It is which application and version originally generated the recovery phrase that still controls my funds?
A user may have created a seed in one wallet, imported it into another app several years later, and forgotten the original source. That history is the information that matters for a generation vulnerability.
Who is not automatically affected?
The Ill Bloom disclosure does not mean every CryptoJS user, every BIP39 wallet, or every software wallet is compromised.
Most mainstream wallet generation paths use cryptographically secure operating-system or browser randomness. A wallet that never used the vulnerable CryptoJS random function to create its recovery phrase is not affected merely because it supports BIP39.
Likewise, a recovery phrase generated independently on a trustworthy hardware wallet is not made weak by the Ill Bloom software-generation bug simply because its public addresses are later viewed through another application.
Import direction matters
Suppose a user securely generates a seed on a hardware wallet and later imports that same seed into unrelated software. The seed's original entropy was not produced by the vulnerable CryptoJS function, although exposing the phrase to software creates other security concerns.
Now reverse the situation. A user creates a weak seed in an affected software wallet and later imports it into a hardware wallet. The hardware device does not repair the secret. It simply stores and signs with the same already predictable keys.
What happened during the confirmed wallet drains?
The vulnerability moved from theoretical cryptographic weakness to documented on-chain exploitation in 2026.
Researchers identified a coordinated drain on May 27, 2026 across addresses in their monitored exposed set. That first documented event affected 431 accounts and moved approximately $3.14 million across Bitcoin, Ethereum, Rootstock, Tron, and Polygon.
Bitcoin represented the majority of value in that first observed sweep, including one individual account containing more than $1 million.
A second drain window occurred from May 30 through July 13. Researchers measured approximately $2.55 million removed from 522 seeds in that event.
Together, the two documented drain events reached approximately $5.69 million in measured stolen funds.
These figures should not be read as a final global loss estimate. They describe measured activity inside the researchers' defined address set and supported chain analysis. Additional derivation paths, wallet software, previously unused accounts, or unsupported chains may fall outside that dataset.
Why one weak recovery phrase can create risk across many chains
A BIP39 recovery phrase can be used as the root for many keys. Wallet standards derive different accounts from that root using deterministic derivation paths.
The same phrase can therefore control a Bitcoin account, an Ethereum address, multiple EVM addresses, Solana accounts, Tron accounts, and other network-specific accounts depending on which derivation paths the wallet supports.
This is one reason seed-level compromise is more serious than compromise of one individual private key.
Moving only your Ethereum balance may not complete the migration
A user may remember using the seed primarily for Ethereum but forget an old Bitcoin balance, an NFT on Polygon, tokens on Base, a Solana account, or assets under a secondary derivation index.
Attackers can derive systematically. Users often remember manually.
A proper migration therefore begins with an inventory of every network, account index, application, staking position, token, NFT, and DeFi position associated with the old recovery phrase.
Public address discovery can continue after the first drain
An address with no current balance can receive funds again in the future. If the underlying seed remains predictable, the newly deposited assets may also be vulnerable.
This creates a long-tail risk. A user might move visible assets but keep the old address saved on an exchange withdrawal whitelist, payment page, ENS record, business invoice, NFT marketplace, payroll system, or contact list.
Months later, new assets can arrive at the same compromised account.
Why importing the same seed into another wallet does not fix Ill Bloom
This is the most important remediation misunderstanding.
A recovery phrase is not a password that another application can strengthen. It is deterministic input from which wallet keys are derived.
If Wallet A generated a weak phrase and the user imports that phrase into Wallet B, Wallet B derives the same private keys. Importing it into Wallet C produces the same keys again.
| Action | Does it fix the weak seed? | Reason |
|---|---|---|
| Update the affected wallet application | No for existing seeds | The update can fix generation of future wallets but cannot change entropy that created an existing phrase. |
| Change wallet application password | No | A local application password protects the encrypted wallet file or interface. It does not change the blockchain private keys. |
| Import the seed into MetaMask or another software wallet | No | The new application derives the same keys from the same weak root secret. |
| Import the seed into a hardware wallet | No | The hardware device can protect future signing operations but cannot add entropy to a phrase generated in the past. |
| Create another account under the same seed | No | All accounts remain deterministically connected to the same underlying weak recovery phrase. |
| Create an entirely new securely generated seed and transfer assets | Yes, for migrated assets | The new wallet uses independent entropy and therefore breaks the attacker's deterministic path from the old seed to the new keys. |
What an Ill Bloom address checker can and cannot prove
Researchers built public-address datasets by enumerating vulnerable candidate seeds, deriving addresses, and matching those addresses against public blockchain activity.
This approach is useful because a user can check a public address without exposing a secret recovery phrase.
A match is strong evidence that the address belongs to a known vulnerable seed set.
A non-match is not equivalent to mathematical proof that the seed is secure.
Why a non-match has limits
Datasets are constrained by the candidate generation configurations, supported languages, derivation paths, blockchain datasets, account indexes, and versions that researchers have processed.
An affected seed that never produced an address in the search scope could remain absent from the current dataset.
Researchers themselves describe the investigation as iterative and the confirmed application list as potentially incomplete.
A website asking you to paste your recovery phrase, mnemonic, private key, keystore password, or backup file to check Ill Bloom exposure creates a much more immediate security risk. A legitimate public-address investigation does not require your secret phrase.
What TokenToolHub Wallet Risk Scanner can tell you
The TokenToolHub Wallet Risk Scanner operates on public wallet information. It can help investigate the observable behavior and exposure of an EVM address, including transaction history, counterparties, assets, approvals, risk indicators, and suspicious interactions supported by the scanner.
That information is useful if you are trying to determine whether a wallet has already interacted with suspicious destinations or whether unexpected movements occurred.
It does not have access to your recovery phrase and cannot determine how much entropy existed when the phrase was generated.
Public on-chain evidence
Transactions, counterparties, approvals, asset activity, suspicious interaction patterns, and other observable address-level signals.
Private seed entropy
Whether a recovery phrase came from CryptoJS, how many entropy bits it contained, whether a secret backup was exposed, or whether somebody has privately reconstructed the seed.
Solana requires the same distinction
If the recovery phrase was also used to derive Solana accounts, the Solana Wallet Risk Scanner can help analyze public account behavior and risk signals on Solana.
Again, it is an on-chain intelligence tool, not an entropy audit.
Investigate the address without exposing the secret
Use public wallet addresses to review transactions, approvals, counterparties, and suspicious movement. Never paste a seed phrase into an address scanner, chatbot, support ticket, form, or vulnerability checker.
What should potentially affected users do?
The correct response depends on whether the recovery phrase may have been generated through a confirmed vulnerable wallet version, whether the wallet still holds assets, and whether unauthorized activity has already started.
The central principle is simple: if the seed itself may be weak, move control of the assets to a genuinely new secret.
Step 1: identify where the recovery phrase was originally generated
Do not start with the application you currently use. Reconstruct the history.
Ask when the wallet was first created, which phone or computer was used, what application generated the words, whether the seed was later imported elsewhere, and whether the current application merely inherited the phrase.
Old screenshots, app-store history, password-manager entries, email records, transaction dates, old devices, and wallet interface memories may help establish the original application.
Step 2: compare that history with confirmed vulnerable software
If the seed originated from RRWallet, Bexo, NanChat, Bitcoin Libre, or Milo during an affected generation period, do not assume current funds are safe because the wallet has not yet been drained.
An attacker can discover and exploit a seed after years of inactivity.
If you cannot determine the generation history but have credible reasons to suspect an affected application or dependency path, the cost of migrating may be much lower than the cost of waiting for certainty.
Step 3: do not expose the seed while investigating
Do not enter the phrase into a website claiming to calculate entropy. Do not send it to wallet support. Do not photograph it for an AI assistant. Do not paste it into a spreadsheet or password form. Do not give it to a Telegram or Discord responder offering help.
A vulnerability that already places seed security in doubt is the worst possible moment to create a second independent compromise.
Step 4: inventory every asset controlled by the old seed
Check all networks you historically used. Include assets held directly and positions represented through smart contracts.
Your inventory may include ETH and ERC-20 tokens, NFTs, staked assets, liquidity-provider positions, lending deposits, collateral, Bitcoin UTXOs, Solana assets, Tron tokens, bridge positions, governance locks, claimable rewards, secondary accounts, and tokens on EVM networks such as Base, Arbitrum, Optimism, Polygon, BNB Chain, Avalanche, Gnosis, Linea, or others.
Step 5: create a completely new wallet
The new wallet must use a recovery phrase generated independently of the old seed.
Do not choose create account inside the old seed and assume the new address solves the problem. A second account index is still derived from the same root secret.
Do not import the old phrase into a new hardware wallet and call that migration.
Generate a genuinely new recovery phrase through a current trustworthy wallet environment using cryptographically secure randomness.
Step 6: verify the new destination carefully
Before moving high-value assets, independently confirm that the destination belongs to the new wallet. Hardware-device users should verify addresses on the device screen when supported instead of trusting only the computer display.
If the situation is not actively being exploited, a small test transfer can help verify the destination and network.
If unauthorized transfers are already occurring, excessive delays and repeated tests can be counterproductive. Prioritize moving remaining assets through a trusted environment as safely as circumstances permit.
Step 7: move assets across every relevant chain
Migrate each asset class and chain rather than stopping after the most obvious balance.
Remember that moving ETH does not move ERC-20 tokens automatically. Moving tokens on Ethereum does not move assets on Base or Arbitrum. Migrating a Solana account does not affect Bitcoin. NFTs and DeFi positions require their own transactions.
Step 8: update deposit destinations and identity references
After migration, change withdrawal whitelists, saved contacts, payment pages, exchange address books, recurring payment instructions, mining or validator payout addresses, ENS-linked addresses where appropriate, public donation addresses, business invoices, and any application that may send funds back to the old wallet.
Step 9: stop treating the old seed as a safe destination
An old compromised wallet can remain dangerous even after its current balance reaches zero.
If new funds arrive later, the attacker may still be able to take them.
Should you move to a hardware wallet?
A hardware wallet can materially improve key isolation because the private signing key remains inside a dedicated device rather than being routinely exposed to a general-purpose computer or phone.
For users replacing a potentially weak software-generated seed, the important requirement is that the hardware wallet generate a new recovery phrase securely on the device.
Importing the old phrase defeats the purpose of this particular migration because the issue is the old secret itself.
A current hardware wallet such as Ledger can be one option for generating and storing a fresh recovery phrase away from a general-purpose computer. Hardware devices still require careful backup practices, authentic-device verification, firmware hygiene, address verification, and protection against phishing. No hardware wallet can make an already predictable imported seed unpredictable.
What if funds have already moved without permission?
Unauthorized outbound transactions are strong evidence that the wallet's signing authority has been compromised, regardless of whether Ill Bloom is ultimately responsible.
Do not focus solely on proving the root cause while additional assets remain exposed.
Preserve evidence while prioritizing the security of remaining funds.
Record the transaction hashes
Transaction hashes provide durable on-chain evidence. Record the chain, timestamp, source address, destination address, asset, amount, and transaction hash.
Decode EVM transactions
The TokenToolHub Transaction Decoder can help identify what an EVM transaction actually executed, including calls, token transfers, approvals, and related execution behavior supported by the decoder.
This helps distinguish a direct unauthorized transfer from an allowance-based token movement, malicious contract interaction, bridge operation, or other transaction path.
Inspect destination reuse
Attackers may consolidate many victims into common collector addresses or use separate fresh destinations before consolidation.
Shared counterparties can help connect what initially look like unrelated wallet drains.
Contact exchanges when relevant
If stolen assets are sent to a known custodial exchange or regulated service, preserve transaction evidence and contact the service through its official security or compliance channel.
Do not expect a blockchain transaction to be reversible. The practical objective is to preserve evidence and identify any point where assets enter infrastructure capable of acting on abuse reports or lawful requests.
Ill Bloom versus phishing, malicious approvals, and malware
Wallet drains are frequently grouped together, but the remediation depends on the compromise mechanism.
| Compromise | What attacker needs | Typical evidence | Does a new seed help? |
|---|---|---|---|
| Ill Bloom weak generation | Ability to reconstruct candidates created by the vulnerable generator | No victim interaction required; valid signatures from reconstructed keys; potentially coordinated cross-chain sweeps | Yes, when assets move to a genuinely new securely generated seed |
| Seed phishing | Victim enters recovery phrase into malicious site or sends it to attacker | Often preceded by fake support, airdrop, migration, verification, or security prompts | Yes, because the old secret is known to attacker |
| Malicious token approval | Victim signs approval granting spender authority | Approval transaction followed by transferFrom or operator-based token movement | Not always necessary if seed remains safe, but approval should be revoked and compromise fully assessed |
| Device malware | Compromise of device, wallet storage, clipboard, browser, or signing environment | Can include secret extraction, address substitution, malicious extension behavior, or unexpected signing | A new seed helps only if generated and used in a clean environment |
| Smart contract exploit | Bug in protocol or contract logic | Many users may lose funds through the same contract path even though individual wallet keys remain private | Usually not a seed issue by itself |
Why changing your wallet password is not enough
Many wallet applications ask users to create a local password. That password can encrypt the wallet's local storage, protect application access, or prevent someone with temporary device access from immediately opening the wallet.
The password is normally not the secret from which blockchain addresses are derived.
If an attacker can independently reconstruct the seed phrase from weak entropy, the attacker does not need the victim's application password.
Changing that password may still be good device hygiene, but it does not solve Ill Bloom exposure.
Why revoking approvals is not enough
Revoking token allowances is important after malicious approval incidents. It can stop a spender contract from moving tokens through previously granted authority.
Ill Bloom is more fundamental.
If an attacker possesses the wallet's actual private keys, the attacker can simply sign new transactions from the account. The attacker does not need an existing token allowance.
Approval cleanup can still be useful during broader wallet hygiene, but it is not a substitute for seed migration when the signing keys themselves may be reconstructable.
A seed phrase is only as strong as its generation process
Security advice often focuses on storage: write the phrase on paper, never screenshot it, keep it offline, use metal backup, never share it.
All of those practices assume the phrase was unpredictable when created.
Ill Bloom demonstrates a different category of failure. A user can follow every backup rule perfectly and still lose funds if the software generated a predictable secret before displaying it.
Entropy generation is part of the trusted computing base
Wallet security begins before the first transaction. The operating system's secure randomness, wallet implementation, dependency graph, entropy handling, derivation library, and backup presentation all form part of the security boundary.
Open source helps investigation but does not guarantee security
Public code can allow researchers to discover vulnerable generation logic and verify fixes. It does not mean every user or developer has audited every dependency.
Closed-source wallets create additional attribution challenges because researchers may need historical APKs, reverse engineering, or vendor cooperation to reconstruct old generation paths.
Ill Bloom is also a software supply-chain lesson
The developer who builds a wallet rarely writes every cryptographic primitive from scratch. Applications depend on package managers, forks, wrappers, mobile compatibility layers, platform APIs, and transitive dependencies.
That ecosystem makes modern software development practical, but cryptographic applications cannot treat every dependency as interchangeable plumbing.
Replacing a secure platform API can silently reduce security
A developer might replace a dependency because it does not work smoothly in React Native or another environment. If the replaced component happened to provide secure entropy and the replacement provides only generic pseudorandom output, the resulting application can remain functionally correct while becoming cryptographically unsafe.
Tests may not detect the weakness
Automated tests can confirm that a wallet creates twelve words, passes a checksum, derives the expected addresses, signs transactions, restores correctly, and produces different phrases in repeated tests.
All those tests can pass while entropy remains predictable.
Randomness quality requires security analysis, not merely functional testing.
Dependency updates do not retroactively protect secrets
Most software vulnerabilities disappear once every user updates to a patched release. Secret-generation vulnerabilities are different.
If vulnerable software created a private key ten years ago, installing the fixed library today cannot change the key already controlling the assets.
What wallet developers should do
Developers should treat wallet-generation code as security-critical infrastructure with explicit cryptographic requirements.
Wallet generation review
- Trace the exact entropy source used for every supported wallet-generation path.
- Verify that randomness comes from a cryptographically secure platform API appropriate to the execution environment.
- Audit historical versions, not only the current release, when a vulnerable dependency was previously present.
- Identify whether vulnerable versions generated secrets or merely used CryptoJS for unrelated cryptographic functions.
- Audit forks of BIP39, HD-wallet, React Native, and cryptographic libraries independently of upstream packages.
- Document version ranges in which recovery phrase generation behavior changed.
- Provide migration workflows that generate an entirely new seed rather than instructing users to import the old one into updated software.
- Warn users clearly when historical secrets cannot be considered repaired by an application update.
- Offer public-address based exposure checks where reliable datasets exist without ever requesting recovery phrases.
- Coordinate disclosure with exchanges, infrastructure providers, wallet teams, and incident-response groups when active exploitation is occurring.
A practical migration checklist for users
If you believe your recovery phrase may be affected
- Do not share or upload the recovery phrase anywhere.
- Identify the application and approximate version that originally generated the phrase.
- Check whether that generation path is among confirmed affected applications or historical versions.
- Review public wallet addresses for unauthorized activity without exposing secrets.
- Inventory assets across every chain and account derived from the seed.
- Create a completely new wallet from securely generated independent entropy.
- Verify the new destination addresses before moving high-value assets.
- Migrate native coins, tokens, NFTs, DeFi positions, staking positions, and other assets systematically.
- Update exchange withdrawal whitelists and any services that still send funds to the old addresses.
- Treat the old seed and all addresses derived from it as permanently unsuitable for future deposits.
- Preserve suspicious transaction hashes and relevant evidence if unauthorized movements occurred.
A public-address investigation workflow
Seed entropy and on-chain activity are different layers of evidence. Combining them carefully produces a more useful incident investigation.
Reconstruct creation origin
Determine which software originally generated the recovery phrase and approximately when the wallet was created.
Analyze public wallet behavior
Review assets, transactions, counterparties, approvals, and unusual outbound movements using public-address intelligence.
Decode suspicious transactions
Inspect exactly what unauthorized or unexpected transactions executed before deciding whether the incident was direct key compromise or another mechanism.
Move to independent entropy
Create a new recovery phrase through a secure generator and systematically migrate every asset and future deposit path.
TokenToolHub Pro can help users who regularly investigate multiple wallets and transactions maintain a more consistent research workflow across the available security tools. See TokenToolHub Pro for the current intelligence workspace and tool access.
Common mistakes after discovering possible Ill Bloom exposure
Moving funds to another address under the same recovery phrase
This changes the derived address but not the compromised root secret. An attacker who reconstructs the phrase can derive additional standard account indexes too.
Believing the current wallet application determines security
The important application is the one that generated the seed. A phrase can pass through many wallet interfaces during its lifetime.
Entering the seed into an online entropy tester
This can convert suspected historical exposure into immediate certain exposure.
Stopping after moving the largest balance
Smaller tokens, NFTs, secondary accounts, staking rewards, and assets on other networks may remain under the old root key.
Using the old address again later
A predictable key does not become safer because the wallet stayed empty for several months.
Assuming no current drain means no attacker knows the seed
An attacker may monitor addresses and wait for future balances, prioritize higher-value accounts, or stage drains in waves.
Assuming the vulnerability is fixed because the wallet vendor released an update
A fixed generator protects newly generated secrets. Historical seeds need an explicit migration path.
Why on-chain forensics still matter when the seed is the root cause
If the vulnerability is cryptographic, it may seem that blockchain analysis adds little. In reality, public ledgers provide crucial evidence.
Researchers can identify groups of exposed addresses, observe coordinated sweep timing, study collector-address reuse, measure losses, correlate activity across chains, and sometimes infer which wallet ecosystem produced a cluster.
That evidence helped move Ill Bloom from an unexplained drain incident to identification of a common weak-generation mechanism.
Cross-chain timing can reveal common control
When accounts derived from related vulnerable seeds move funds across several chains within narrow time windows, the pattern can indicate automated sweeping rather than unrelated users independently moving assets.
Destination fan-in can reveal consolidation
Hundreds of victim accounts sending toward a small number of collector destinations is different from ordinary independent wallet activity.
Historical funding reveals how long the vulnerability remained dormant
An address can exist safely for years not because its seed is strong, but because nobody has yet discovered or exploited the weakness.
Time without theft is not proof of cryptographic strength.
Did BIP39 fail?
No. BIP39 specifies how entropy becomes mnemonic words and how those words are converted into seed material.
It assumes the entropy source is suitable for cryptographic use.
Ill Bloom demonstrates what happens when software satisfies the mnemonic specification but violates that security assumption.
Standards cannot rescue bad entropy
Hashing predictable input can produce output that looks random without restoring the missing uncertainty. Encoding weak entropy into a standardized phrase likewise does not create the vast search space that should have existed before encoding.
Security principles users should carry forward
Recovery phrase security principles
- A recovery phrase should be generated by trustworthy software or hardware using a cryptographically secure source of randomness.
- Never treat visual randomness as evidence of cryptographic randomness.
- Never enter a recovery phrase into a website to check whether it is vulnerable.
- A wallet application update cannot repair weak entropy already embedded in an existing recovery phrase.
- Changing software does not change keys when the same seed is imported.
- Creating another account under the same recovery phrase does not create a new root secret.
- Seed compromise should trigger cross-chain asset inventory because one root can control many networks and accounts.
- Wallet scanners analyze public blockchain evidence, not hidden seed entropy.
- Transaction decoders help explain what happened on-chain but cannot prove how the wallet seed was generated.
- Hardware wallets improve secret isolation only when the secret itself was securely generated.
Using security tools without confusing their purpose
No single scanner can answer every wallet-security question because wallet incidents span different layers.
| Question | Useful evidence | What it cannot prove alone |
|---|---|---|
| Was my seed generated by affected software? | Wallet creation history, vulnerable app/version evidence, known exposed-address datasets | A normal blockchain explorer cannot reconstruct historical application entropy automatically |
| Has my EVM wallet interacted with suspicious addresses? | Wallet risk analysis, counterparties, transaction history, approvals and public labels | Whether the seed phrase is predictable |
| Has my Solana account shown suspicious behavior? | Solana wallet activity, counterparties, assets and public risk indicators | Whether BIP39 entropy was generated securely |
| What did a suspicious EVM transaction do? | Calldata decoding, transfers, approvals, traces and logs where available | Who possessed the private key or how they obtained it |
| Is my seed safe to keep using? | Generation provenance and cryptographic implementation history | No public-address risk score can certify private seed entropy |
Why undiscovered affected wallets may still matter
The confirmed list contains five applications, but researchers have deliberately avoided presenting that list as exhaustive.
The vulnerable code existed for years. JavaScript and React Native code is frequently forked, copied, adapted, vendored, and abandoned. Some wallets may have disappeared from app stores. Some historical versions may no longer be publicly downloadable. Others may have rebranded or used the vulnerable generation logic only during a narrow release period.
That creates a forensic problem: vulnerable seeds can outlive the software that created them.
Inactive wallets can become attractive later
An empty exposed wallet is not necessarily worth attacking today. If it later receives a large deposit, automated monitoring can make it relevant again.
New datasets can reveal older exposure
As researchers analyze more derivation paths, languages, seed lengths, application configurations, and historical chain data, addresses that were absent from an earlier exposure dataset may be identified later.
Worked examples: how users should reason about Ill Bloom
Example one: Bexo seed created years ago, app is now updated
A user created a wallet in an older Bexo version, wrote down the phrase, later updated the application, and continues using the same wallet.
The update may correct generation for new wallets, but the old seed remains unchanged. The user should evaluate the historical phrase as potentially affected and migrate to a newly generated independent seed if it falls within the vulnerable generation path.
Example two: vulnerable seed imported into MetaMask
A user no longer has the original affected wallet installed. Years ago, the same phrase was imported into MetaMask and the user now considers it a MetaMask wallet.
The underlying seed remains the phrase generated by the original application. MetaMask does not retroactively provide fresh randomness when importing a phrase.
Example three: vulnerable seed imported into a hardware wallet
A user buys a hardware wallet and chooses restore existing recovery phrase instead of creating a new phrase on the device.
The hardware wallet can protect signing operations from malware, but an Ill Bloom attacker who reconstructs the original phrase does not need the hardware device. Both parties derive the same keys.
Example four: current public-address checker reports no match
A user remembers creating a wallet with historical software known to have vulnerable versions, but the public address does not appear in the current exposed-address dataset.
A non-match reduces one specific evidence signal, but it does not prove that the seed was generated with full entropy. Dataset coverage is necessarily limited by the derivation paths, languages, candidate spaces, and chain data processed so far.
Example five: wallet risk scan shows no malicious counterparties
The wallet has normal transaction history and no suspicious counterparties. That is useful evidence about its on-chain behavior.
It does not prove the seed is cryptographically strong. A predictable seed can remain untouched until an attacker chooses to drain it.
Example six: one unauthorized ETH transfer appears
A user sees ETH leave the wallet with a correctly signed transaction they did not authorize.
The immediate problem is private-key compromise. Record the transaction, investigate the destination, inspect whether other assets remain, and move remaining funds to an independent secure wallet if safe to do so.
Later analysis can determine whether Ill Bloom, seed phishing, malware, or another cause best explains the compromise.
Example seven: only a token moved through transferFrom
If an attacker used a previously granted allowance rather than signing directly from the victim address, the event may be an approval compromise rather than seed compromise.
Decode the transaction before assuming every drain involving an affected wallet is caused by weak entropy.
Example eight: user moved Ethereum but forgot Solana
The same BIP39 phrase was once imported into a multichain wallet. The user moves all EVM assets to a fresh seed but leaves a Solana account active.
If that Solana account is derived from the same vulnerable root, the migration remains incomplete.
A monitoring framework after migration
Moving assets is the priority, but users and organizations may still want to monitor abandoned addresses for evidence of attempted exploitation or accidental future deposits.
Watch compromised addresses
Monitor old public addresses for unexpected deposits, sweeps, or activity that provides additional incident evidence.
Verify destination hygiene
Confirm the new wallet uses independent entropy and has not inherited unsafe approvals or account settings from the old environment.
Update payment destinations
Replace old addresses across exchanges, businesses, dApps, contact lists, withdrawal whitelists, and recurring flows.
Preserve forensic records
Keep transaction hashes, dates, old application versions, addresses, and relevant vendor communications if losses occurred.
What exchanges and crypto businesses should learn from Ill Bloom
The incident also matters to organizations that never generated a vulnerable wallet themselves.
Exchanges can receive stolen assets. Custodians can hold funds originating from vulnerable addresses. Security providers can detect coordinated sweeps. Wallet vendors can unknowingly inherit insecure dependencies. Developers can copy code from old repositories.
Address-risk systems need historical context
An address draining hundreds of seemingly unrelated wallets can become an important indicator even when each individual victim transaction has a valid cryptographic signature.
Valid signatures are not proof of legitimate ownership
Blockchain protocols can verify that the correct key signed a transaction. They cannot determine whether the signer was the intended human owner or an attacker who reconstructed a weak seed.
Secret-generation audits deserve the same priority as signing audits
Security reviews often focus on transaction signing, secure enclaves, key encryption, and phishing resistance. The random-generation path that creates the key should receive equal scrutiny.
Conclusion: Ill Bloom shows why wallet security starts at generation
The Ill Bloom wallet vulnerability is a reminder that self-custody security begins before a user backs up the recovery phrase, before a private key signs its first transaction, and before an address receives its first asset.
A recovery phrase can be perfectly valid according to BIP39 and still be unsafe if the software that created its entropy was predictable.
CVE-2026-71851 exposed exactly that failure. Vulnerable CryptoJS randomness reached wallet-generation code through downstream dependency paths. Some software wallets then created phrases whose effective search space was dramatically smaller than the nominal security level users expected.
Attackers did not need to defeat Bitcoin, Ethereum, Solana, or another blockchain. They could recreate the vulnerable generation process offline, derive candidate addresses, compare them against transparent public-chain activity, and obtain valid private keys for funded wallets.
The confirmed affected software currently includes RRWallet, Bexo Wallet, NanChat, Bitcoin Libre, and Milo, but researchers explicitly warn that other applications may exist. That uncertainty is why wallet creation history matters.
The remediation is also different from ordinary application vulnerabilities. A patched app cannot add entropy to a secret generated years ago. A new password cannot repair the key. Importing the seed into another wallet cannot repair it. A new account under the same phrase cannot repair it.
Users with credible exposure should create a genuinely new recovery phrase using trustworthy cryptographically secure generation and migrate every relevant asset and account away from the old root secret.
Public-address intelligence remains valuable during that process. Use the Wallet Risk Scanner to investigate EVM wallet behavior, the Solana Wallet Risk Scanner for Solana account intelligence, and the Transaction Decoder when suspicious EVM transactions need to be understood at the call and transfer level.
Those tools answer questions about what is visible on-chain. They deliberately do not ask for or inspect the private recovery phrase.
That boundary matters. The recovery phrase should remain secret even when you are investigating whether its original generation was secure.
The durable security principle is straightforward: protect the seed after generation, but also care about how the seed was generated in the first place. Strong storage cannot compensate for weak entropy.
Investigate wallet activity without exposing your recovery phrase
Start with public addresses and transaction evidence. Review suspicious counterparties, approvals, asset movements, and transaction execution while keeping the recovery phrase completely offline.
FAQs
What is the Ill Bloom wallet vulnerability?
Ill Bloom is a wallet-generation vulnerability involving recovery phrases created with insufficient randomness. Several software wallet applications used a vulnerable CryptoJS randomness implementation, allowing attackers to search a much smaller candidate space than a properly generated BIP39 phrase should provide.
What is CVE-2026-71851?
CVE-2026-71851 tracks insufficient entropy in security-sensitive secret generation through vulnerable CryptoJS randomness. The Ill Bloom investigation connected that weakness to downstream wallet applications that used CryptoJS.lib.WordArray.random() to generate BIP39 recovery phrase entropy.
Was BIP39 itself broken?
No. BIP39 defines how entropy is represented as mnemonic words and transformed into seed material. Ill Bloom occurred because the input entropy was generated insecurely before BIP39 encoding.
Which wallets are confirmed affected by Ill Bloom?
The currently confirmed applications are RRWallet, Bexo Wallet, NanChat, Bitcoin Libre, and Milo. Researchers state that the list may not be exhaustive.
Which Bexo Wallet version fixed the issue?
The published Ill Bloom application analysis identifies Bexo Wallet version 20.1.0 as the fixed version. Existing recovery phrases created through a vulnerable historical version still require separate evaluation and migration.
Which NanChat version fixed the issue?
NanChat fixed the vulnerable generation path in version 1.3.0 and provided migration handling for affected wallets.
Which Bitcoin Libre version fixed the issue?
Researchers identify Bitcoin Libre version 4 as the fixed generation version. Some versions before version 4 included the vulnerable entropy-generation library.
Are RRWallet and Milo still supported?
The Ill Bloom disclosure lists RRWallet and Milo as discontinued applications, meaning users cannot rely on a current software update as a remediation path for historical seeds.
Does updating my wallet fix an old weak recovery phrase?
No. An update can correct how new wallets are generated, but it cannot change entropy that produced an existing recovery phrase. A potentially weak historical seed must be replaced with an independently generated secure seed.
Can I import the affected seed into another wallet to make it safe?
No. Importing the same recovery phrase into another application derives the same underlying keys. Changing wallet software does not create fresh entropy.
Does importing the affected seed into a hardware wallet fix it?
No. A hardware wallet can securely store and use the imported key, but an attacker able to reconstruct the original seed can derive the same private keys independently. A secure migration requires a newly generated seed.
Does creating another account under the same recovery phrase solve the problem?
No. Additional accounts remain deterministic children of the same root seed. An attacker with the recovery phrase can derive standard account indexes as well.
Why does the recovery phrase still look random?
The phrase is valid BIP39 output. Weakness exists in the limited set of entropy values that the vulnerable generator could produce, which is not visible from the mnemonic words themselves.
How much entropy should a twelve-word BIP39 phrase have?
A standard twelve-word BIP39 phrase is normally based on 128 bits of entropy plus checksum information. That corresponds to an astronomically large space when the entropy source is cryptographically secure.
How much effective entropy did the vulnerable CryptoJS path provide?
The Ill Bloom technical disclosure estimates effective search spaces of approximately 2^39 possibilities for nominal 128-bit generation and approximately 2^47 for nominal 256-bit generation under the vulnerable implementation.
How much money was stolen through Ill Bloom?
The researchers measured approximately $5.69 million across two documented drain events in their monitored dataset. They describe the figure as a lower bound rather than a complete estimate of every potentially affected wallet.
When did the first confirmed Ill Bloom drain happen?
The first documented coordinated drain identified in the Ill Bloom research occurred on May 27, 2026.
Which chains were involved in the first documented drain?
The May 27 analysis documented drained accounts across Bitcoin, Ethereum, Rootstock, Tron, and Polygon within the researchers' monitored address set.
Can one weak recovery phrase affect several blockchains?
Yes. A BIP39 recovery phrase can derive multiple network-specific accounts through deterministic derivation paths. One compromised root phrase can therefore expose assets across several chains.
Is a wallet safe if it has not been drained yet?
Not necessarily. A predictable recovery phrase can remain unused by attackers for years before it is discovered or prioritized. Lack of previous theft does not prove the underlying entropy is secure.
Can I check Ill Bloom exposure using only my public wallet address?
Researchers have built public-address based exposure datasets that can identify known matches without requiring private secrets. A match is important evidence, while a non-match should not be interpreted as mathematical proof that every possible vulnerable derivation path has been excluded.
Should I ever enter my recovery phrase into an Ill Bloom checker?
No. Never enter your recovery phrase, mnemonic, private key, wallet backup, or keystore password into an online exposure checker. A public-address checker does not need those secrets.
Can TokenToolHub Wallet Risk Scanner detect weak seed entropy?
No. The Wallet Risk Scanner analyzes public wallet information and on-chain risk signals. It cannot inspect a private recovery phrase or determine how much entropy existed when that phrase was generated.
What can the Wallet Risk Scanner help with?
It can help investigate public EVM wallet behavior such as assets, transactions, counterparties, approvals, and supported risk signals, which can be useful when reviewing whether suspicious activity has already occurred.
Can the Solana Wallet Risk Scanner determine whether my seed is weak?
No. It analyzes public Solana wallet behavior. Seed entropy is a private generation property that cannot be certified from an ordinary public wallet scan.
What should I do if my seed may have been generated by an affected wallet?
Create an entirely new recovery phrase through a trustworthy cryptographically secure generator, verify the new addresses carefully, inventory every asset controlled by the old seed, and migrate those assets to the new wallet.
Should I change my wallet password?
Changing a local wallet password can improve device security, but it does not repair Ill Bloom exposure because the blockchain keys derive from the recovery phrase rather than the application's local password.
Should I revoke token approvals?
Approval cleanup can be useful security hygiene, but revoking approvals does not solve weak-seed compromise. An attacker who can derive the wallet's private key can sign new transactions directly.
Should I use a hardware wallet when migrating?
A reputable hardware wallet can be a strong option when it generates a completely new seed securely on the device. Restoring the potentially weak old recovery phrase onto the device does not fix Ill Bloom exposure.
What if funds have already been stolen?
Record transaction hashes and destination addresses, analyze suspicious transactions and counterparties, secure any remaining assets using a new independent wallet, and contact relevant exchanges or service providers through official channels when stolen assets enter identifiable custodial infrastructure.
How can I tell whether an unauthorized transaction was a seed compromise or malicious approval?
Inspect the transaction itself. A direct transaction signed from the victim account differs from a token movement executed through a previously approved spender. Transaction decoding and approval history can help distinguish the mechanisms.
Can a future deposit to an old vulnerable address also be stolen?
Yes. If the old private key remains reconstructable, future assets sent to the same address can remain exposed. Update withdrawal whitelists, payment instructions, public donation addresses, and saved contacts after migration.
Does the presence of CryptoJS in an app automatically mean the wallet is vulnerable?
No. The vulnerability applies when the weak random function is actually used to generate security-sensitive entropy. Applications may use CryptoJS for unrelated cryptographic functions without using it for wallet generation.
References and further reading
The following primary security disclosures, advisories, and standards provide additional technical detail on Ill Bloom, CVE-2026-71851, the affected wallet applications, on-chain drain analysis, and BIP39 recovery phrase generation.
- Ill Bloom: Crypto Wallet Vulnerability
- Technical Disclosure: The CryptoJS Randomness Vulnerability
- Identifying the Wallets Behind Vulnerable Recovery Phrases
- Wallet Drain of May 2026 Analysis
- Second Wave of Wallet Drains Analysis
- Ill Bloom Dataset Construction Methodology
- GitHub Security Advisory: CVE-2026-71851
- BIP-39: Mnemonic Code for Generating Deterministic Keys
This TokenToolHub guide is security research and educational material. The Ill Bloom investigation remains active, additional affected applications or addresses may be identified, and remediation guidance from wallet vendors can evolve. Never submit a recovery phrase or private key to TokenToolHub or any public address scanner. When seed-generation security is uncertain, use independent secure wallet generation and carefully migrate assets rather than relying on the old secret.
