Research paper: Based on materials from Coinspect Research / Ill Bloom (2026)

An investigation by Ill Bloom revealed that the security of a crypto wallet is determined not only by the mathematical strength of ECDSA, secp256k1, or BIP39, but also by the quality of the initial entropy. The Coinspect team linked a series of active underruns to an insecure generator CryptoJS.lib.WordArray.random(): with nominal 128 and 256 bits of input entropy, the effective search space was reduced to approximately 239 ^and 247 ^states . Therefore, the attack did not require solving ECDLP and was not a «Bitcoin hack»: it boiled down to a reproducible enumeration of weak mnemonics, deterministic derivation of addresses, and comparison with public blockchain data.

The article systematizes the cryptanalytic incident model, the application attribution procedure, the specifics of responding to ongoing theft, and practical requirements for supply chain audits. Operationally dangerous details that accelerate exploitation are intentionally omitted.

Keywords: BIP39, entropy, CSPRNG, CryptoJS, MWC, HD wallets, cryptanalysis, blockchain analysis, dependency tracing, coordinated vulnerability disclosure.

Statement of the problem

In May 2026, Coinspect began investigating an incident involving wallet withdrawals across multiple networks. The initial hypothesis about a single product was replaced by a more general one: a vulnerable recovery phrase generation mechanism could have been propagated for years through reused JavaScript dependencies and library forks.

The essence of the incident lies in the violation of the uniform randomness assumption. The user saw a standard 12- or 24-word phrase, but the actual set of possible phrases was significantly smaller than expected. This turns seemingly cryptographically strong key material into a brute-force attack.

Cryptographic model

Normal BIP39 scheme

In a typical scheme, the mnemonic is constructed from entropy ENTand a checksum CS. For 12 words, ENT = 128 is typically used, for 24 words, ENT = 256; the checksum length is defined as ENT/32. The bit string is then divided into groups of 11 bits, each of which indexes a word in a dictionary of 2048 elements.

CS = first_ENT/32_bits(SHA256(ENT))
MS = ENT || CS
N_words = (ENT + ENT/32) / 11

The mnemonic is then converted into a PBKDF2-HMAC-SHA512 seed, from which the HD wallet derives the master key and child keys via specified derivation paths. In an ideal model, the difficulty of guessing 128-bit entropy is approximately 2,128 ^, which is practically unachievable.

Collapse of effective entropy

In Ill Bloom, the vulnerable path used a MWC-like PRNG instead of a CSPRNG. Therefore, the nominal length of the requested random byte array is not equal to the number of independent unpredictable bits. If the internal state of the generator has an effective uncertainty h , then the upper bound for the brute-force attack is determined not by 2 ^ENT , but by 2 ^h .

|S_effective| ≈ 2^h
Work_factor ≈ 2^(h-1) (average number of checks in equiprobable search)
Security_loss = ENT - h

According to the published technical documentation, the spaces estimated for the affected cases were approximately 239 ^and 247 ^, representing a loss of approximately 89 and 209 bits relative to the nominal 128 and 256 bits, respectively. The BIP39 checksum does not compensate for this loss: it verifies the integrity of the encoding rather than adding independent secret randomness.

Attack chain

Stage	Cryptanalytic meaning	Observed result
1. Weak generation	The application uses a vulnerable CryptoJS path as an ENT source.	The mnemonic belongs to a small set of achievable PRNG outputs.
2. Reproduction of candidates	The researcher models admissible states and obtains candidate mnemonics.	Instead of attacking the hash or ECDSA, a brute force attack on a weak source is used.
3. Derivation	For each mnemonic, the seed, keys, and addresses in supported networks and paths are calculated.	The result is a verifiable set of public identifiers.
4. On-chain matching	Addresses are compared with transaction history and balances.	Actual and potentially vulnerable accounts are identified.
5. Theft	The attacker has the private key after restoring the mnemonic.	Funds are transferred through regular valid transactions.

Crucially, blockchain makes the final verification particularly efficient. The address, balance, and transaction history are publicly available; therefore, brute-force testing requires no interaction with the owner, the wallet server, or the authentication mechanism.

Historical analogues

Ill Bloom belongs to the well-known class of «weak randomness destroys strong cryptography» failures. Historical incidents demonstrate that the vulnerability often lies at the implementation level, not the underlying cryptographic primitive.

Case	Failure mechanism	Connection with Ill Bloom
Debian OpenSSL (2006–2008)	A mistaken change in the PRNG initialization dramatically reduced the set of possible keys.	As here, mathematically correct RSA/DSA operations did not save keys created from a small state space.
Android Bitcoin RNG (2013)	Insufficient randomness in ECDSA signatures resulted in repeated/predictable nonces and private key extraction.	The common root is the misuse of randomness; the difference is that in the first place, the signature’s nonce was compromised, while here, the original mnemonic was compromised.
Low-entropy IoT keys	Devices generate keys either before system entropy accumulates or from deterministic parameters.	Shows that platform portability and convenience cannot justify replacing CSPRNGs with home-made PRNGs.

These examples confirm the cryptanalytic principle: one should evaluate not the stated key size, but the minimum entropy and the actual size of the space from which the key was actually chosen.

Technical root cause

The vulnerability, identified as CVE-2026-71851, is related to CryptoJS.lib.WordArray.random(). In the affected CryptoJS variants, the function relied on a custom variant of Multiply-With-Carry (MWC), a family of generators developed by George Marsaglia that is not intended for generating cryptographic secrets.

Historically, the MWC implementation was introduced in the CryptoJS 3.1.2-4 line in June 2014. According to the technical disclosure, it remained in most 3.x releases, excluding 3.2.0 and 3.2.1; access to the platform’s cryptographic randomness source was restored in version 4.0.0 in February 2020.

Important: the presence of a package 

crypto-jsin the dependency tree does not in itself prove a risk. The vulnerability applies when the affected function is actually used to generate sensitive secrets—in this case, BIP39 entropy.

Distribution via dependencies

The investigation identified a specific supply chain vulnerability: a fork ferrumnet/bip39created for React Native replaced an upstream dependency randombyteswith pure JavaScript CryptoJS. Meanwhile, the upstream approach was receiving randomness from crypto.randomBytesNode.js or crypto.getRandomValuesthe browser.

This replacement appears to solve the cross-platform problem, but it changes the trust model: instead of the OS or browser’s CSPRNG, an application-specific generator with limited internal state is introduced. In audits, this requires not only analysis of manifest files but also tracing the data flow from the wallet generation API to the entropy source.

Investigation Methodology

Reconstruction and verification

Coinspect generated candidate recovery phrases for the vulnerable process, derived the corresponding addresses, and compared them with blockchain data. The analysis was expanded to include networks, derivation paths, entropy values, and mnemonic languages, as these parameters generate different sets of addresses.

The scientific value of this approach lies in separating two tasks: (1) demonstrating that a weak generator is capable of producing a specific mnemonic, and (2) demonstrating that this mnemonic actually corresponded to the on-chain account used. The second stage rules out abstract false hypotheses and links the implementation defect to the observed damage.

App Attribution

The public address doesn’t contain metadata about the application that created the wallet. Therefore, Coinspect combined clustering and contextualization of on-chain activity, open-source code analysis, dependency tracing, and reverse engineering of historical APKs of closed or discontinued products.

Confirmed software	Status/remediation	Line of evidence
RRWallet (RenrenBit)	Discontinued; no fix available	Source code supplemented with on-chain links to the RenrenBit ecosystem.
Bexo Wallet	Active; fixed in 20.1.0	Dependency analysis and controlled validation using victim mnemonics.
NanChat	Active; fixed in 1.3.0	Tracing the dependency to the wallet generation flow; confirmed by the project team.
Bitcoin Libre	Active; fixed in version 4	On-chain traces, historical APK, and developer verification.
Milo	Discontinued; no fix available	Activity concentration: 96% of the selected 256-bit subset received the Milo token in Polygon; then reconstructing the historical APK.

Response during operation

Disclosing such a vulnerability has a dual effect. A detailed technical publication helps owners and developers identify the risk, but it also lowers the barrier to attack; therefore, the initial disclosure concealed the exact source of the weak randomness until protective measures were implemented.

Coinspect created a public address verification service and shared sets of vulnerable addresses, along with evidence, with relevant participants for risk assessment, notification, and mitigation efforts. Address verification does not reveal the owner, but creates a channel for the owner to learn about the risk without deanonymization.

Formal risk assessment

For cryptographic auditing, it is useful to distinguish between nominal and effective strength. Let Gbe the algorithm for obtaining ENT, and Sbe the set of its actually achievable outputs. Then the entropy estimate is defined as:

H_effective = log2(|S|)
R = ENT - H_effective
P(success after q trials) ≈ min(q / |S|, 1)

For a correct CSPRNG with ENT = 128, the expected value is |S| ≈ 2 ¹²⁸ . For Ill Bloom, the researchers estimated the space of some generations to be around 2 ³⁹ ; this is not «slightly weaker,» but a qualitatively different threat class, allowing for mass offline verification of candidates and addresses.

Requirements for secure implementation

1. Receive ENT only from the CSPRNG platform: crypto.getRandomValues()in the browser, crypto.randomBytes()in Node.js, system CSPRNGs in native applications.
2. For keys, seeds, nonces, and tokens Math.random(), prohibit MWC, LCG, xorshift, and any home-made PRNGs without cryptographic justification.
3. Conduct SBOM and lockfile audits, but be sure to supplement them with an analysis of the actual call: “package installed” does not equal “vulnerable code generates a secret.”
4. Test the entropy origin invariant: The automated test should confirm that the path createWallet()reaches the CSPRNG, not a polyfill or fallback branch.
5. If the risk of generating entirely new mnemonics on a fixed implementation and transferring assets is confirmed, updating the application does not make the old weak phrase secret.

// Conceptual secure scheme for the browser
const entropy = new Uint8Array(32);
crypto.getRandomValues(entropy);
// entropy is then passed to the verified BIP39 implementation.
// Do not replace crypto.getRandomValues() with Math.random() or CryptoJS WordArray.random().

Limitations and interpretation

The list of confirmed apps should not be considered exhaustive. Historical builds may have disappeared, closed apps cannot be fully verified, and the same defect may only exist in limited versions, platforms, or configurations.

It’s also impossible to infer a vulnerability solely from the seed phrase format, the network used, or the presence of CryptoJS in the project. A reproducible chain of evidence is required: application version → dependency → specific generator call → mnemonic parameters → reproducible addresses → on-chain confirmation.

Conclusion

Ill Bloom is a telling case of applied cryptanalysis, in which the attack target was not secp256k1 or BIP39, but a source of randomness preceding them. Strong subsequent cryptography is unable to restore secrecy if the original entropy has already been reduced to an enumerable set.

For the industry, the key takeaway is practical: wallet generation is a critical cryptographic protocol, not a back-end interface feature. Its security must be proven at the execution level, dependencies, archived releases, and the entropy source—especially in cross-platform JavaScript and React Native stacks.

Sources

Ill Bloom: Crypto-Analytical Investigation of Wallet Generation Vulnerability: https://usde.ru/ill-bloom-crypto-analytical-investigation-of-wallet-generation-vulnerability/

1. Coinspect. Ill Bloom: Investigating a Wallet Generation Vulnerability During Active Exploitation, 2026.
2. Ill Bloom. Technical Disclosure: The CryptoJS Randomness Vulnerability, 2026.
3. Ill Bloom. Identifying the Wallets Behind Vulnerable Recovery Phrases, 2026.
4. BIP-0039. Mnemonic code for generating deterministic keys.
5. GitHub Security Advisory GHSA-rg76-677x-56q9; CVE-2026-71851.