Ill Bloom is the name of a wallet generation vulnerability, tracked as CVE-2026-71851 . Its cryptanalytic nature lies not in the compromise of ECDSA, secp256k1, SHA-256, or BIP39 as standards, but in a catastrophic reduction in entropy before the BIP39 mnemonic generation stage. Research by Coinspect linked the incidents to an insecure implementation CryptoJS.lib.WordArray.random()using a variant of the Multiply-With-Carry (MWC) generator. For nominal 128 and 256 bits of entropy, the effective search spaces are estimated to be approximately 2^39 and 2^47, respectively. This transforms brute-force attacks from practically impossible to computationally feasible with targeted searches and comparisons with public blockchain data.
The Ill Bloom interactive checker accepts only public addresses, performs a local check against a published set of known exposed addresses, and does not require a mnemonic, private key, or backup file. A match should be interpreted as an indicator of seed phrase compromise and grounds for immediate migration of funds to a completely new wallet; a negative answer does not constitute cryptographic proof of security.
Keywords: BIP39, HD wallets, entropy, CSPRNG, CryptoJS, MWC, CVE-2026-71851, PBKDF2, BIP32, public address, on-chain forensics, cryptanalysis.
1. Statement of the problem
The security of self-storage cryptoassets is usually described in terms of the strength of elliptic curve cryptography. However, the practical chain of trust begins earlier: with the generation of an unpredictable secret. If the initial entropy is weak, correct hash functions, key-definition functions, and signatures deterministically propagate this weakness without eliminating it.
Ill Bloom is a prime example of “implementation cryptanalysis”: the attacker fails to solve the discrete logarithm on secp256k1 and fails to guess a random 12-word phrase from the full BIP39 space. They reproduce the flawed generation process, iterate over a significantly smaller set of states, obtain valid mnemonics, and match the derived public addresses with observed chains.
2. Factual base
The technical disclosure links the vulnerability to CryptoJS 3.x: the MWC implementation was introduced in June 2014 in version 3.1.2-4, was absent from 3.2.0 and 3.2.1, then returned in 3.3.0; the platform’s cryptographic randomness source was restored in CryptoJS 4.0.0 in February 2020. The presence of a dependency alone does not prove a vulnerability: it is the use of this function for secrets, in particular for BIP39 entropy, that is critical.
The published description lists five verified software wallets: RRWallet, Bexo, NanChat, Bitcoin Libre, and Milo. The first confirmed on-chain evidence of exploitation dates back to May 27, 2026; the researchers also describe a second wave between May and July and a separate episode associated with a Chinese mnemonic subset on July 20-21.
3. Cryptographic model
3.1 Normal BIP39 generation
For 12 words, BIP39 uses 128-bit entropy and a 4-bit checksum, after which the 132 bits are divided into 11-bit word indices. The nominal size of the original entropy space is:
ENT = 128; CS = ENT / 32 = 4; MS = ENT + CS = 132; |S| = 2^128.
The mnemonic isn’t a standalone source of security: it’s an encoding of the initial secret with a checksum. BIP39 then specifies the seed using PBKDF2-HMAC-SHA512, and BIP32 deterministically derives the extended keys and addresses.
seed = PBKDF2-HMAC-SHA512(mnemonic, “mnemonic” || passphrase, 2048, 512).
3.2. Entropy Collapse
In Ill Bloom, a nominal query of 128 or 256 bits did not yield the corresponding effective uncertainty. Public GitHub advisories indicate approximately 2^39 and 2^47 possible results. The equivalent entropy loss is approximately 89 bits for the 128-bit case and approximately 209 bits for the 256-bit case.
H_eff(128) ≈ 39, ΔH ≈ 128 – 39 = 89 bits.
H_eff(256) ≈ 47, ΔH ≈ 256 – 47 = 209 bits.
Even 2^39 is a huge value for manual brute-force, but it is orders of magnitude smaller than 2^128. The main lesson: the cryptographic strength of a system is limited by the weakest link in the secret’s lifecycle, not by the length of the output of the subsequent KDF.
3.3 Why PBKDF2 Doesn’t Fix the Bug
PBKDF2 can increase the cost of checking each candidate, but it cannot increase the number of independent unknown bits. If the generator selects a value from a set A, then after any deterministic function f, the set of possible results does not exceed |A|:
|f(A)| ≤ |A|, therefore H_min(f(X)) ≤ H_min(X).
Similarly, SHA-256, HMAC, and BIP32 derivation cryptographically correctly transform a weak secret, but do not transform it into a strong one. This is the fundamental difference between “cryptographic processing” and “entropy extraction.”
4. Chain of exploitation
The publication does not disclose attack optimizations, so only a high-level defense-analytics model is provided below, sufficient for auditing and understanding the risk.
- The compatible behavior of the vulnerable generator is reproduced and the reduced space of possible outputs is enumerated.
- Candidates are converted into valid BIP39 mnemonics with a verifiable checksum.
- From each candidate, keys and public addresses are deterministically derived using common BIP44/BIP49/BIP84 and network paths.
- Derived addresses are matched against public on-chain activity indices; a match links the candidate to the observed address.
- A confirmed seed compromises all supported addresses derived from it, including those not yet used and located on other networks.
# Security model pseudocode (not operational code) for candidate in reduced_entropy_domain: mnemonic = bip39_encode(candidate) seed = bip39_seed(mnemonic, passphrase=””) for path in audited_derivation_paths: address = derive_public_address(seed, path) if address in public_activity_index: mark_seed_and_related_addresses_exposed()
A historical example. In the Milk Sad incident (2023), vulnerable Bitcoin wallets also arose due to insufficient entropy during the creation of key material. The general pattern is the same: predictable generation reduces the candidate space, and public observability of the blockchain allows filtering by the presence of funds or activity. The specific PRNGs, software stacks, and scope differ.
5. Address set
Ill Bloom Exposed Address Set 1 (June 2026) covers only 12-word BIP39 phrases with 128-bit entropy, English, and selected non-English dictionaries. The methodology is intentionally iterative: it is not a universal vulnerability oracle, but a published snapshot of a specific search space, networks, and derivation paths.
| Stage | Action | Scientific meaning |
|---|---|---|
| Seed detection | Candidate phrases are matched against addresses from public blockchain sets; in the first step, index 0 of account 0 is checked. | Reduces computational costs and uses on-chain activity as a discriminator of correct candidates. |
| Address extension | For the found seed, additional addresses and paths are deterministically output regardless of their current balance. | The risk is related to the seed, not the individual address; this prevents a false sense of security for inactive derived addresses. |
For the initial discovery, Ethereum/EVM m/44'/60'/0'/0/0, Tron m/44'/195'/0'/0/0, Bitcoin P2PKH m/44'/0'/0'/0/0, P2WPKH, m/84'/0'/0'/0/0 and P2SH-P2WPKH paths were published m/49'/0'/0'/0/0. The extension includes a number of accounts and indices, as well as Rootstock, Cosmos, Solana, and Nano. Public Google BigQuery datasets were used as the matching base: approximately 1.5 billion Bitcoin addresses from transaction outputs, 341 million Ethereum senders, 190 million EVM senders across several networks, and 254 million Tron addresses based on TRC20/balance criteria.
6. Checker’s work
The Ill Bloom web tool is designed to verify the full public address of an EVM, Bitcoin, Tron, Solana, or EOS network. According to the service description, the address is not sent to the server: the browser detects the network and locally calculates the token/search feature to access the current set.
This is an important privacy feature, but it doesn’t change the trust model: users must verify URLs, not install unknown extensions, and never enter mnemonics, private keys, passwords, or wallet backups. A public address is sufficient for membership verification; entering secrets is not only unnecessary but also creates a phishing risk.
Interpretation of the result. “Match” means the address is in the current set of known exposed addresses; the seed phrase should be considered compromised. “No match” only means it’s not in the current set—not the absence of a vulnerability, as coverage constraints include the seed phrase type, dictionary, path, index, network, and discovery stages.
7. Limitations and fallacies
| Incorrect conclusion | Why is he unfaithful? | Correct interpretation |
|---|---|---|
| “CryptoJS < 4.0.0 is a dependency, meaning the wallet is hacked.” | The vulnerability requires the use WordArray.random() of security-sensitive generation. | We need an analysis of the data flow from the RNG to the mnemonic, key, nonce, or other secret. |
| “No match means safety” | The set of addresses is incomplete and limited to the published scope. | This is a negative result for a specific database, not a proof of cryptographic strength. |
| “Just update the app” | The seed already created remains the same weak secret. | Create a new wallet with a new phrase and transfer assets to new addresses. |
| “Importing your old phrase into your hardware wallet is safe.” | The hardware device protects storage but does not add entropy to an already known attacker seed. | What is needed is a new independent generation, not a transfer of a compromised phrase. |
8. Historical context
Ill Bloom belongs to a recurring class of flaws: the use of a shared PRNG, predictable seeds, small state spaces, or misinitialization for long-lived secrets. In cryptanalysis, this class is particularly dangerous because an attacker can enumerate candidates offline, and the blockchain provides a global public test of correctness through addresses, transactions, and UTXOs.
| Happening | General Cryptanalytic Lesson | Connection with Ill Bloom |
|---|---|---|
| Debian OpenSSL (2006–2008) | A seemingly minor change in the randomness source reduced the key space to enumerable. | The failure is in the generation of secrets, and subsequent cryptography does not compensate for the lost entropy. |
| Android SecureRandom/Bitcoin (2013) | Bad randomness for an ECDSA nonce can reveal the private key even with correct curve math. | The security of the signature depends on the correctness of the randomness in the implementation. |
| Trust Wallet browser extension (released 2022–2023) | The limited space of mnemonic generation allows for targeted enumeration and monitoring of addresses. | Identical operating model: weak seed generation plus public address verification. |
| Milk Sad (2023) | An inappropriate PRNG when creating wallets produces recoverable private keys. | A direct analogy with Ill Bloom as a vulnerability of the source of entropy. |
9. Recommendations for owners
- Verify public addresses through the official interface; do not submit any sensitive information in the form.
- If there is a match, consider all assets controlled by the same phrase to be at risk across all chains and derivation paths.
- On a trusted device, create a new wallet with a new phrase, preferably with a hardware key source or a verified CSPRNG implementation.
- Transfer assets, including tokens and funds in other networks; do not send new deposits to old addresses.
- Don’t confuse restoring an old wallet with creating a new one: requesting an existing phrase means importing, not remediating.
- If there is no match, evaluate the history of the application used, the version, and the method of initial phrase creation; for suspicious old software wallets, consider preventative migration.
10. Recommendations for developers
To generate secrets, use only system CSPRNGs: the Web Crypto API crypto.getRandomValues() in the browser environment and crypto.randomBytes() in Node.js. Do not use Math.random()custom PRNGs, timestamps, device identifiers, unaudited fallbacks, or library functions with non-obvious cryptographic semantics.
// Safe minimum for browser source of 128-bit entropy const entropy = new Uint8Array(16); crypto.getRandomValues(entropy); // Then pass entropy to a verified BIP39 implementation. // You cannot replace getRandomValues() with Math.random().
Supply chains must maintain fixed dependency versions, conduct SBOM and transitive dependency audits, test the actual generation path rather than just package presence, and implement negative tests to prevent non-CSPRNGs. GitHub advisory lists crypto-js versions below 4.0.0 as affected and recommends 4.0.0+ or direct use of native cryptographic APIs.
11. Responsible Disclosure
Ill Bloom’s public value lies in combining technical disclosure, on-chain forensics, and a secure diagnostic interface. However, the publication should exclude operational details that facilitate unauthorized seed listings and focus on identifying victims, migrating funds, notifying vendors, and fixing systemic bugs.
Ill Bloom’s materials mention the Blockchain Security Alliance in the context of the information ecosystem and industry exchange; the technical primary attribution of the CVE, the description of the mechanism, the address set methodology, and the checker itself were published by Coinspect and the GitHub Advisory Database. Therefore, it is scientifically correct to separate the roles: the researcher and operator of the set—Coinspect; the independent tracker of dependencies and recommendations—GitHub Advisory; industry partners should not be automatically considered the authors of the technical proof without a separate primary publication.
12. Final Provisions
Ill Bloom demonstrates that the real security of a crypto wallet is determined not only by the strength of the primitives used, but also by the amount of unpredictability introduced before their use. A drop in the effective space from 2^128 to about 2^39 changes the nature of the threat: instead of abstract impossibility, the problem of reproducible search with public verification using blockchain traces emerges.
A public address checker is a useful damage mitigation mechanism, but it’s not an absolute security check. Its proper use requires a strict ban on sharing secrets, an understanding of the seed’s limitations, and immediate cryptographic rotation—generation of a new independent seed and asset migration—when a match is confirmed.
Sources
Ill Bloom: Crypto Wallet Vulnerability and Public Exposure Checker: https://treep.ru/ill-bloom-crypto-wallet-vulnerability-and-public-exposure-checker/
- Coinspect. Ill Bloom: Crypto Wallet Vulnerability , accessed September 2026.
- Coinspect. Technical Disclosure: The CryptoJS Randomness Vulnerability , 2026.
- Coinspect. Dataset Construction Methodology , Ill Bloom Exposed Address Set 1, June 2026.
- GitHub Advisory Database. GHSA-rg76-677x-56q9: crypto-js insufficient entropy , August 2026.
- BIP-0039: Mnemonic code for generating deterministic keys; BIP-0032: Hierarchical Deterministic Wallets; BIP-0044, BIP-0049, BIP-0084.