No phishing. No cloud backup. No photo. A newly disclosed wallet flaw shows that a recovery phrase can fail before the owner ever writes it down.
Imagine doing everything right.
You create a new crypto wallet.
The app gives you a recovery phrase.
You write the words on paper.
You never photograph them.
You never put them in Notes.
You never upload them to Google Drive.
You never type them into a website.
The paper stays offline for years.
And one day, the wallet is drained anyway.
At first, that sounds impossible.
If nobody stole the recovery phrase, how could anyone reconstruct the wallet?
The answer is uncomfortable:
What if the recovery phrase was never truly unpredictable in the first place?
That is the security lesson behind a newly disclosed vulnerability known as Ill Bloom.
And it changes the way I think about seed phrase security.
A Seed Phrase Is Only as Strong as the Randomness Behind It
Most users look at a 12-word or 24-word recovery phrase and assume:
“There are so many possible combinations that nobody could ever guess this.”
Normally, that assumption is reasonable.
But the words themselves are not the security.
The real security comes from the entropy used to generate them.
Entropy is simply the unpredictable randomness behind the secret.
If the randomness is strong, the resulting recovery phrase can be extraordinarily difficult to predict.
If the randomness is weak, something that looks random to a human may come from a much smaller set of possibilities.
That is exactly what happened here.
Researchers investigating Ill Bloom found that some wallet applications had generated recovery phrases using a vulnerable randomness function from the CryptoJS library.
The vulnerable function did not provide the amount of unpredictability the wallets appeared to request.
For nominal 128-bit and 256-bit values, researchers found effective search spaces of roughly 2³⁹ and 2⁴⁷ possibilities instead.
Those numbers are still large.
But cryptographically, they are nowhere near what users thought they were getting.
And that difference was enough to matter.
This Wasn't Just a Theoretical Bug
Security vulnerabilities are easy to dismiss when they exist only in laboratory demonstrations.
Ill Bloom is different.
Researchers identified real blockchain addresses derived from vulnerable recovery phrases and documented coordinated drain events.
In one analyzed event on May 27, 2026, 431 accounts across Bitcoin, Ethereum, Tron, Rootstock and Polygon were drained for approximately $3.14 million. The investigation later documented additional losses, with the measured lower bound reaching roughly $5 million by mid-July.
The frightening part is how little the owner needed to do wrong.
The user did not necessarily:
- reveal the seed,
- install malware after creating the wallet,
- fall for fake support,
- upload the phrase to the cloud,
- or approve a malicious transaction.
The weakness could already exist at wallet creation.
Five Wallet Applications Have Been Confirmed So Far
Coinspect's Ill Bloom research currently names five applications confirmed to have generated recovery phrases through the vulnerable mechanism:
- RRWallet
- Bexo
- NanChat
- Bitcoin Libre
- Milo
Researchers also caution that additional affected applications may exist.
That last sentence matters.
A public blockchain address normally does not tell researchers which wallet application originally generated its recovery phrase.
So identifying every downstream application that used the vulnerable code takes time.
It is also important not to overstate the problem:
Simply using CryptoJS did not automatically make a wallet vulnerable.
The application needed to use the affected randomness function for security-sensitive generation such as a recovery phrase.
That distinction prevents a technical vulnerability from turning into unnecessary panic.
The Most Important Detail: Updating the App Is Not Enough
Suppose a wallet developer discovers a vulnerable random-number generator.
They fix it.
You install the newest version.
Problem solved?
Not necessarily.
Software updates can fix future generation.
They cannot retroactively add randomness to a secret that was created years earlier.
Think about it this way.
If an old wallet generated:
Seed A
using weak randomness, installing an update does not transform Seed A into:
Seed B
Seed A is still Seed A.
Its history cannot be rewritten.
The GitHub security advisory for CVE-2026-71851 makes this explicit: previously generated secrets may remain exploitable, and simply updating the affected software does not strengthen an old secret.
This leads to an even more important point.
Moving the Same Seed to a Hardware Wallet Does Not Fix It Either
This is where hardware-wallet users need to pay attention.
Imagine someone created a recovery phrase years ago with vulnerable software.
They later decide:
“I'll make it safer by importing this seed into a hardware wallet.”
The private keys are now being used through hardware.
But the original recovery phrase has not changed.
If the phrase itself came from a predictable generation process, moving it onto better hardware does not magically add missing entropy.
You have moved the same secret.
You have not created a new one.
Researchers specifically warn that importing the affected recovery phrase into another software wallet or hardware wallet does not remediate the vulnerability.
That is one of the most useful lessons from this incident:
Better storage cannot repair a secret that was weak when it was created.
We Spend So Much Time Protecting the Seed After Generation
Most seed phrase security advice begins after the phrase appears.
Don't photograph it.
Don't upload it.
Don't email it.
Don't give it to support.
Don't store it beside the hardware wallet.
Protect it from water.
Protect it from fire.
Protect it from theft.
All of that still matters.
I write about those risks constantly.
But Ill Bloom introduces a step that should come before all of them:
Where did this recovery phrase come from?
Was it generated by:
- a reputable hardware wallet,
- a well-maintained open-source wallet,
- an unknown web page,
- an old browser wallet,
- a discontinued mobile app,
- a homemade script,
- or software whose randomness implementation you know nothing about?
You can protect a piece of paper perfectly.
That does not tell you whether the secret written on it was generated correctly.
“24 Words” Is Not a Security Certification
This is another misconception worth killing.
Users see 24 English words and think:
“That must be extremely secure.”
Not automatically.
The phrase is a representation of underlying information.
A wallet could theoretically show you 24 perfectly valid-looking BIP39 words generated from bad randomness.
The output looks normal.
The weakness exists underneath it.
It is similar to a password generator that produces:
f8K!q3zP$92b
It looks strong.
But if the generator secretly chooses from only 10,000 possible passwords, appearances do not matter.
An attacker attacks the generator's possible outputs.
Not your perception of randomness.
Why Attackers Don't Need to “Guess Your Words” One by One
People often imagine seed cracking like this:
attacker guesses word 1
then word 2
then word 3...
That is not the relevant model.
If attackers understand the flawed generation method, they can reproduce possible outputs of that generator.
For each candidate secret, they can derive blockchain addresses.
Public blockchains then give them something extremely useful:
a way to check whether the candidate corresponds to an address that has actually been used.
They do not need your phone.
They do not need your Ledger.
They do not need your recovery card.
They can perform much of the search offline and compare derived addresses against public blockchain activity.
That is why weak entropy is such a dangerous class of wallet failure.
The Blockchain Becomes the Attacker's Verification System
There is an uncomfortable asymmetry in cryptocurrency.
Wallet creation is private.
Wallet activity is public.
That means a bad wallet generator can create a private weakness whose results later become visible on-chain.
Once an address receives funds, an attacker searching a reduced key space has something to look for.
The blockchain effectively answers:
“Did I find a real wallet?”
This is one reason cryptographically secure randomness matters so much at the moment of wallet creation.
There is no account lockout.
No CAPTCHA.
No bank asking why thousands of possible keys were tested.
The protection is supposed to come from the search space being impossibly large.
Reduce that search space enough, and the threat model changes.
How Would You Know If Your Wallet Is Affected?
Coinspect created a checker for the known Ill Bloom datasets.
The important safety detail is that it only requires a public wallet address.
It does not require:
- your recovery phrase,
- private key,
- wallet backup,
- password,
- or seed file.
Researchers explicitly warn users never to enter those secrets into the checker.
There is another important limitation:
A negative result does not prove that every wallet is safe.
The published datasets cover specific recovery-phrase types, networks and derivation paths and are not exhaustive.
That makes the checker useful evidence.
Not a universal certificate of safety.
What If Your Wallet Matches?
The remediation is conceptually simple, even if moving a portfolio can be inconvenient.
If a recovery phrase was generated through an affected process, researchers recommend creating a new wallet with a completely new recovery phrase from a trustworthy generation source and migrating funds to addresses derived from the new wallet.
The key word is:
new.
Not:
Import old seed.
Not:
Restore old wallet on new hardware.
Not:
Change the wallet password.
Not:
Update the old app and continue using the same addresses.
A new cryptographic root is required.
Because the old root is the problem.
This Is Why I Separate “Generation Security” From “Backup Security”
I now think of seed phrase security as at least three separate questions.
1. Was the recovery phrase generated securely?
This is the Ill Bloom problem.
2. Has the recovery phrase remained secret?
This includes phishing, malware, screenshots, cloud storage and physical copying.
3. Will the recovery phrase still exist when the legitimate owner needs it?
This includes fire, water, paper degradation, accidental disposal and poor recovery planning.
Solving one does not solve the other two.
A perfectly generated seed can be stolen.
A perfectly private seed can be physically destroyed.
And a perfectly protected physical backup can still represent a recovery phrase that was weak from birth.
That is why “my seed phrase is offline” is important—but incomplete.
Hardware Wallets Help, but the Details Still Matter
A reputable hardware wallet can reduce dependence on a general-purpose computer or phone during key generation and signing.
That can be valuable.
But I would still avoid the lazy conclusion:
“Hardware wallet = impossible to have weak keys.”
Security depends on the implementation, firmware, generation process and recovery workflow.
We've already seen in 2026 that hardware wallets themselves can suffer generation problems too.
The larger lesson is not to worship one device category.
It is to understand where the randomness comes from and how the secret is created.
For long-term holdings, I want seed generation to happen through a process I can reasonably trust—and I want the resulting backup to remain offline afterward.
Those are separate requirements.
The Physical Backup Still Matters After You Fix Generation
Ill Bloom is a software-generation failure.
Once you create a fresh, securely generated seed, the problem changes again.
Now you still have to protect that recovery path for years.
Paper can be lost.
Digital copies can leak.
A backup can be stored beside the wallet.
A phrase can become unreadable.
Family members can discard it without knowing what it is.
That is the physical side of self-custody.
I maintain a separate guide at CryptoSafeKit covering seed phrase storage risks, paper versus metal backups, geographic separation and recovery planning:
Seed Phrase Storage: Dangerous Mistakes and Reliable Long-Term Backup Strategies
The important point is that storage products do not fix Ill Bloom.
They solve a different layer.
A durable metal backup can help preserve a good seed.
It cannot make a weak seed stronger.
That distinction is exactly how security products should be evaluated.
The Question I Would Ask Every Old Wallet
This incident has changed one of the questions I ask about wallets I created years ago.
I used to ask:
Where is the seed phrase?
Now I also ask:
What generated it?
Do I remember?
Which application?
Which version?
Was it created on a hardware wallet?
Was it created in a browser?
Was it generated by an old mobile app I no longer use?
Was it imported from somewhere else?
For a wallet created yesterday, those answers are easy.
For a wallet created six years ago, they may not be.
That uncertainty is itself useful information.
Your Recovery Phrase Has a Birth Certificate
Maybe that is the easiest way to think about all of this.
A seed phrase has two histories.
The history after creation:
Where did you store it?
Who saw it?
Was it photographed?
Did it survive?
And the history of its creation:
What software generated it?
What randomness source did that software use?
Was the implementation trustworthy?
Ill Bloom is a reminder that we spend almost all our time protecting the first history.
Sometimes the second one is where the failure began.
One Question for the Comments
Think about the oldest wallet you still control.
Do you actually remember what generated its recovery phrase?
Not where you store it.
Not whether it is 12 or 24 words.
What software or hardware created it in the first place?
I'm curious how many long-term crypto users can answer that confidently.
Please do not post wallet addresses, seed phrases, private keys, passphrases or balances in the comments.
Security disclaimer: This article is for educational purposes only. Ill Bloom currently concerns recovery phrases generated through confirmed vulnerable software paths; merely using CryptoJS does not automatically mean a wallet is affected. If you believe a wallet may be affected, consult the original security research and current wallet-vendor guidance before acting. Never enter a recovery phrase, private key, password or wallet backup into an unsolicited checker or website.
