2026-08-09 · view entry permalink →
CVE-2026-71851 — crypto-js below 4.0.0 generates 'random' values with about 2^39 of real entropy, and attackers were draining wallets built on it while the investigation ran
The defect is not a bug in a cryptographic primitive but in what fed one. CryptoJS.lib.WordArray.random() in affected versions is a custom variation of George Marsaglia's Multiply-With-Carry PRNG seeded from Math.random(), introduced in 3.1.2-4 in June 2014 and present in every 3.x release except 3.2.0 and 3.2.1 (GitHub Advisory Database, 2026-08-07). The consequence is a collapse in real entropy rather than a bias a statistical test would flag: "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" (GitHub Advisory Database, 2026-08-07). The version history is its own trap: the generator was fixed in 3.2.0 and 3.2.1, and "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 it with the platform's native cryptographic API (GitHub Advisory Database, 2026-08-07).
Coinspect reached the root cause from the other end, starting in May 2026 from a wallet-drain incident across multiple networks that was initially attributed to a single product (Coinspect, 2026-08-05). Its reconstruction reimplemented the affected generator, enumerated the feasible PRNG outputs, converted candidate entropy values into valid BIP39 recovery phrases, derived addresses across the relevant derivation paths and networks, and matched them against public blockchain data to recover the private keys controlling funded addresses (GitHub Advisory Database, 2026-08-07). That method is also why the investigation ran under pressure: Coinspect states the flaw "had existed for more than a decade, making it difficult to determine how widely the vulnerable implementation had spread, and attackers were already exploiting it while our investigation was underway" (Coinspect, 2026-08-05). The advisory records coordinated drain waves against addresses derived from vulnerable phrases, with a measured lower bound of approximately $5M in stolen assets across the two events as of 2026-07-13 (GitHub Advisory Database, 2026-08-07).
For a defender outside the cryptocurrency sector the wallet framing understates the exposure. The advisory's scope rule cuts both ways: "An application is affected only if it uses the vulnerable function to generate security-sensitive values" and merely depending on crypto-js < 4.0.0 is not sufficient to be exploitable — but any use of that function for a key, token, session identifier or password-reset code produces a value inside the same enumerable space. Two properties make it worse than a normal dependency finding. The generator's weakness is not visible in an application's own source, because the call site looks like a request for cryptographic randomness; and the damage does not age out. The advisory is explicit that updating the library does not strengthen a previously generated secret, that importing the same recovery phrase into updated software does not remediate it, and that previously generated secrets may remain exploitable indefinitely (GitHub Advisory Database, 2026-08-07).
Detection is therefore a code-and-inventory exercise rather than a telemetry one: there is no network or endpoint artefact for a secret that was weak at birth, and an attacker enumerating offline generates no traffic against the victim at all. The tractable signal is the software bill of materials — a resolved crypto-js version below 4.0.0 in a build manifest, lockfile, container layer or bundled front-end asset — paired with a search of the codebase for WordArray.random at security-sensitive call sites.
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.
The vulnerability had existed for more than a decade, making it difficult to determine how widely the vulnerable implementation had spread, and attackers were already exploiting it while our investigation was underway.
Applying PBKDF2, another KDF, or a cryptographic hash after the vulnerable generator does not restore missing entropy.