Summary
crypto-js: Insufficient Entropy in Cryptographic Secret Generation via Vulnerable CryptoJS Dependency Chain
CryptoJS.lib.WordArray.random() in affected versions is not a cryptographically secure random number generator. Nominal requests for 128 or 256 bits of entropy produce effective search spaces of approximately 2^39 and 2^47 possibilities, small enough to enumerate on commodity hardware.
Coinspect's Ill Bloom investigation confirmed that downstream wallet applications used this function as the entropy source for BIP39 recovery phrases.
An application is affected only if it uses the vulnerable function to generate security-sensitive values.
Merely depending on crypto-js < 4.0.0 is not sufficient to be exploitable.
Details
The affected implementation used a custom variation of George Marsaglia's Multiply-With-Carry PRNG, seeded from Math.random(). It was introduced in 3.1.2-4 (June 2014, commit brix/crypto-js@ff1f003) in response to issue #7, and was present in every 3.x release except 3.2.0 and 3.2.1. That change was reverted in 3.3.0 because it was considered a breaking change, so projects tracking the 3.x line could resolve to newer versions that still contained the weak generator.
4.0.0 replaced the generator with the platform's native cryptographic API.
Applying PBKDF2, another KDF, or a cryptographic hash after the vulnerable generator does not restore missing entropy.
Proof of concept
Coinspect reproduced the attack end to end:
- Reimplemented the affected
WordArray.random()behavior. - Enumerated the feasible outputs of the underlying PRNG.
- Converted candidate entropy values into valid BIP39 recovery phrases.
- Derived private keys and addresses across the relevant derivation paths and networks.
- Compared derived addresses against public blockchain data.
- Recovered the private keys controlling funded addresses.
Public address checker
Coinspect provides a public checker for addresses identified in the known Ill Bloom exposed-address datasets:
Only public blockchain addresses should be entered. Users must never enter a recovery phrase, seed phrase, mnemonic, private key, password, or wallet backup file.
A match indicates that funds controlled by the same recovery phrase may be at immediate risk. A negative result only means that the submitted address was not found in the currently published datasets.
References
- Ill Bloom research site and public address checker:
https://illbloom.org/ - Coinspect investigation overview:
https://www.coinspect.com/blog/ill-bloom-investigation/ - CryptoJS issue #7,
randomBytes is not random enough:
https://github.com/brix/crypto-js/issues/7 - Commit introducing the MWC-based implementation:
https://github.com/brix/crypto-js/commit/ff1f0032ff58aedfcc44eb6aa7b2c78207a98009 - Changes between CryptoJS
3.3.0and4.0.0:
https://github.com/brix/crypto-js/compare/3.3.0...4.0.0 - Downstream
ferrumnet/bip39fork:
https://github.com/ferrumnet/bip39
Impact
An attacker can enumerate the reduced output space and recover security-sensitive values generated through the affected function.
Coinspect documented coordinated drain waves affecting addresses derived from vulnerable recovery phrases. As of July 13, 2026, the measured lower bound of stolen assets across the two events was approximately $5M.
The consequences are persistent:
- Updating an affected library or wallet does not strengthen a previously generated secret.
- Importing the same recovery phrase into an updated software or hardware wallet does not remediate the issue.
- Previously generated secrets may remain exploitable indefinitely.
- Future deposits to an affected address may also be stolen.
- Assets may remain exposed across networks or derivation paths that have not yet shown suspicious activity.
CVE-2026-71851 has a CVSS score of 9.0 (Critical). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (4.0.0); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
For projects:
- Upgrade
crypto-jsto version4.0.0or later. Where possible, replace CryptoJS randomness with the native Web Crypto API or Node.jscryptomodule. - Audit direct, downstream, and transitive dependencies for versions of
crypto-jsmatching< 4.0.0. - Determine whether
CryptoJS.lib.WordArray.random()was used to generate any security-sensitive values. - Identify the time periods and application versions during which the vulnerable generation path was present.
- Treat all long-term secrets generated through an affected path as compromised and rotate them.
- Notify affected users that installing an update is insufficient when a long-term secret was generated by the vulnerable code.
For wallet users: create a new wallet with a newly generated recovery phrase from a trustworthy source and migrate assets to addresses derived from it. Do not import the existing recovery phrase into the new wallet.
Frequently Asked Questions
- What is CVE-2026-71851? CVE-2026-71851 is a critical-severity security vulnerability in crypto-js (npm), affecting versions < 4.0.0. It is fixed in 4.0.0.
- How severe is CVE-2026-71851? CVE-2026-71851 has a CVSS score of 9.0 (Critical). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of crypto-js are affected by CVE-2026-71851? crypto-js (npm) versions < 4.0.0 is affected.
- Is there a fix for CVE-2026-71851? Yes. CVE-2026-71851 is fixed in 4.0.0. Upgrade to this version or later.
- Is CVE-2026-71851 exploitable, and should I be worried? Whether CVE-2026-71851 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-71851 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-71851? Upgrade
crypto-jsto 4.0.0 or later.