CVE-2026-71851: crypto-js Insufficient Entropy Vulnerability

CRITICAL
Advisory Identifier: GHSA-rg76-677x-56q9
CVSS 9.0
CWE-331 CWE-338 CWE-334
Published
Advisory Summary

CVE-2026-71851 is a CRITICAL (CVSS 9.0) insufficient entropy vulnerability (CWE-331: Insufficient Entropy) affecting crypto-js libraries in the npm ecosystem. The issue involves insufficient entropy in cryptographic secret generation via vulnerable cryptojs dependency chain. Remediation is available by upgrading affected packages to version 4.0.0.

CVE-2026-71851 at a Glance

CVE Identifier CVE-2026-71851
GHSA Identifier GHSA-rg76-677x-56q9
Severity CRITICAL
CVSS v3.1 Base Score 9.0
CWE Classification CWE-331: Insufficient Entropy
Affected Product crypto-js
Package Ecosystem npm
Published Date
Last Updated

Security Impact

CVSS: 9.0

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H).

Attack Vector Network (AV:N)
Attack Complexity High (AC:H)
Privileges Required None (PR:N)
User Interaction None (UI:N)
Scope Changed (S:C)
Confidentiality High (C:H)
Integrity High (I:H)
Availability High (A:H)

How to Fix CVE-2026-71851

To remediate this vulnerability, upgrade all affected crypto-js dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

crypto-js fixed: 4.0.0
npm install crypto-js@4.0.0
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

npm ls crypto-js

How to Check if You Are Affected

To determine whether your Node.js application is affected by CVE-2026-71851, inspect your project dependencies using npm:

npm ls crypto-js

Analyze the terminal output to locate any version of crypto-js in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 4.0.0), your application is affected.

Note: The npm ls crypto-js command inspects dependencies declared in your package.json and lockfile; it does not perform automated runtime dynamic scanning.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-331: Insufficient Entropy, where the product uses an algorithm or scheme that produces insufficient entropy, leaving patterns or clusters of values that are more likely to occur than others. In crypto-js, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

### Summary `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](https://www.coinspect.com/blog/ill-bloom-investigation/) 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: 1. Reimplemented the affected `WordArray.random()` behavior. 2. Enumerated the feasible outputs of the underlying PRNG. 3. Converted candidate entropy values into valid BIP39 recovery phrases. 4. Derived private keys and addresses across the relevant derivation paths and networks. 5. Compared derived addresses against public blockchain data. 6. Recovered the private keys controlling funded addresses. ### 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. ### Remediation **For projects:** 1. Upgrade `crypto-js` to version `4.0.0` or later. Where possible, replace CryptoJS randomness with the native Web Crypto API or Node.js `crypto` module. 2. Audit direct, downstream, and transitive dependencies for versions of `crypto-js` matching `< 4.0.0`. 3. Determine whether `CryptoJS.lib.WordArray.random()` was used to generate any security-sensitive values. 4. Identify the time periods and application versions during which the vulnerable generation path was present. 5. Treat all long-term secrets generated through an affected path as compromised and rotate them. 6. 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. ### Public address checker Coinspect provides a public checker for addresses identified in the known Ill Bloom exposed-address datasets: [https://illbloom.org/](https://illbloom.org/) 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/](https://illbloom.org/) * Coinspect investigation overview: [https://www.coinspect.com/blog/ill-bloom-investigation/](https://www.coinspect.com/blog/ill-bloom-investigation/) * CryptoJS issue \#7 — `randomBytes is not random enough`: [https://github.com/brix/crypto-js/issues/7](https://github.com/brix/crypto-js/issues/7) * Commit introducing the MWC-based implementation: [https://github.com/brix/crypto-js/commit/ff1f0032ff58aedfcc44eb6aa7b2c78207a98009](https://github.com/brix/crypto-js/commit/ff1f0032ff58aedfcc44eb6aa7b2c78207a98009) * Changes between CryptoJS `3.3.0` and `4.0.0`: [https://github.com/brix/crypto-js/compare/3.3.0...4.0.0](https://github.com/brix/crypto-js/compare/3.3.0...4.0.0) * Downstream `ferrumnet/bip39` fork: [https://github.com/ferrumnet/bip39](https://github.com/ferrumnet/bip39)

CVE-2026-71851 Affected crypto-js Versions

1 component(s)
Fixed Versions:
4.0.0
Product / Package Ecosystem Affected Versions Fixed Version
crypto-js
npm
< 4.0.0
4.0.0

References

Frequently Asked Questions

What is CVE-2026-71851?
CVE-2026-71851 is a security vulnerability in crypto-js involving Insufficient Entropy in Cryptographic Secret Generation via Vulnerable CryptoJS Dependency Chain under CWE-331: Insufficient Entropy.
Which crypto-js versions are affected?
Affected versions include releases prior to 4.0.0 across affected packages: crypto-js.
What version fixes CVE-2026-71851?
Upgrading to 4.0.0 (or the latest patched release for your respective branch) resolves the vulnerability.
Is crypto-js affected?
Yes, crypto-js is affected in releases prior to 4.0.0. Upgrade your dependency to 4.0.0 or later.
What is the CVSS score of CVE-2026-71851?
CVE-2026-71851 has a CVSS v3.1 base score of 9.0 (CRITICAL) with vector string CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H.
What CWE is associated with CVE-2026-71851?
CVE-2026-71851 is classified under CWE-331: Insufficient Entropy (The product uses an algorithm or scheme that produces insufficient entropy, leaving patterns or clusters of values that are more likely to occur than others.).
How can I check npm dependencies for CVE-2026-71851?
Run the dependency tree command: 'npm ls crypto-js'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-rg76-677x-56q9",
  "modified" : "2026-08-07T18:48:59Z",
  "published" : "2026-08-07T18:48:59Z",
  "aliases" : [ "CVE-2026-71851" ],
  "summary" : "crypto-js: Insufficient Entropy in Cryptographic Secret Generation via Vulnerable CryptoJS Dependency Chain",
  "details" : "### Summary\n\n`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.\n\nCoinspect's [Ill Bloom](https://www.coinspect.com/blog/ill-bloom-investigation/) investigation confirmed that downstream wallet applications used this function as the entropy source for BIP39 recovery phrases.\n\n**An application is affected only if it uses the vulnerable function to generate security-sensitive values.** \n\nMerely depending on `crypto-js < 4.0.0` is not sufficient to be exploitable.\n\n### Details\n\nThe 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. \n\n4.0.0 replaced the generator with the platform's native cryptographic API.\n\nApplying PBKDF2, another KDF, or a cryptographic hash after the vulnerable generator does not restore missing entropy.\n\n### Proof of concept\n\nCoinspect reproduced the attack end to end:\n\n1. Reimplemented the affected `WordArray.random()` behavior.  \n2. Enumerated the feasible outputs of the underlying PRNG.  \n3. Converted candidate entropy values into valid BIP39 recovery phrases.  \n4. Derived private keys and addresses across the relevant derivation paths and networks.  \n5. Compared derived addresses against public blockchain data.  \n6. Recovered the private keys controlling funded addresses.\n\n### Impact\n\nAn attacker can enumerate the reduced output space and recover security-sensitive values generated through the affected function.\n\nCoinspect 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.\n\nThe consequences are persistent:\n\n* Updating an affected library or wallet does not strengthen a previously generated secret.  \n* Importing the same recovery phrase into an updated software or hardware wallet does not remediate the issue.  \n* Previously generated secrets may remain exploitable indefinitely.  \n* Future deposits to an affected address may also be stolen.  \n* Assets may remain exposed across networks or derivation paths that have not yet shown suspicious activity.\n\n### Remediation\n\n**For projects:**\n\n1. Upgrade `crypto-js` to version `4.0.0` or later. Where possible, replace CryptoJS randomness with the native Web Crypto API or Node.js `crypto` module.  \n2. Audit direct, downstream, and transitive dependencies for versions of `crypto-js` matching `< 4.0.0`.  \n3. Determine whether `CryptoJS.lib.WordArray.random()` was used to generate any security-sensitive values.  \n4. Identify the time periods and application versions during which the vulnerable generation path was present.  \n5. Treat all long-term secrets generated through an affected path as compromised and rotate them.  \n6. Notify affected users that installing an update is insufficient when a long-term secret was generated by the vulnerable code.\n\n**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.\n\n### Public address checker\n\nCoinspect provides a public checker for addresses identified in the known Ill Bloom exposed-address datasets:\n\n[https://illbloom.org/](https://illbloom.org/)\n\nOnly public blockchain addresses should be entered. Users must **never enter a recovery phrase**, seed phrase, mnemonic, private key, password, or wallet backup file.\n\nA 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.\n\n### References\n\n* Ill Bloom research site and public address checker:  \n  [https://illbloom.org/](https://illbloom.org/)  \n* Coinspect investigation overview:  \n  [https://www.coinspect.com/blog/ill-bloom-investigation/](https://www.coinspect.com/blog/ill-bloom-investigation/)  \n* CryptoJS issue \\#7 — `randomBytes is not random enough`:  \n  [https://github.com/brix/crypto-js/issues/7](https://github.com/brix/crypto-js/issues/7)  \n* Commit introducing the MWC-based implementation:  \n  [https://github.com/brix/crypto-js/commit/ff1f0032ff58aedfcc44eb6aa7b2c78207a98009](https://github.com/brix/crypto-js/commit/ff1f0032ff58aedfcc44eb6aa7b2c78207a98009)  \n* Changes between CryptoJS `3.3.0` and `4.0.0`:  \n  [https://github.com/brix/crypto-js/compare/3.3.0...4.0.0](https://github.com/brix/crypto-js/compare/3.3.0...4.0.0)  \n* Downstream `ferrumnet/bip39` fork:  \n  [https://github.com/ferrumnet/bip39](https://github.com/ferrumnet/bip39)",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "npm",
      "name" : "crypto-js"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "4.0.0"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/brix/crypto-js/security/advisories/GHSA-rg76-677x-56q9"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/brix/crypto-js/commit/b405ff597fb3ac76a7bdfbc72dca10ba1079b1d5"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/brix/crypto-js"
  }, {
    "type" : "WEB",
    "url" : "https://www.coinspect.com/blog/ill-bloom-investigation"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-331", "CWE-334", "CWE-338" ],
    "severity" : "CRITICAL",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-08-07T18:48:59Z",
    "nvd_published_at" : null
  }
}