Severity by source
AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H
Offline brute force over public data needs no auth or interaction (PR:N/UI:N) but requires the app to have used the weak generator for secrets (AC:H); recovered keys expose and let attackers steal funds in downstream wallet systems (S:C, C/I/A:H).
Primary rating from Vendor (https://github.com/brix/crypto-js).
CVSS VectorVendor: https://github.com/brix/crypto-js
Lifecycle Timeline
3Blast Radius
ecosystem impact- 505 npm packages depend on crypto-js (143 direct, 367 indirect)
Ecosystem-wide dependent count for version 4.0.0.
DescriptionCVE.org
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 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.
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:
- 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.
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:
- 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:
Articles & Coverage 1
AnalysisAI
Insufficient-entropy secret generation in the crypto-js npm library (all 3.x releases except 3.2.0/3.2.1, i.e. versions < 4.0.0) collapses CryptoJS.lib.WordArray.random() to effective search spaces of only ~2^39 (128-bit request) and ~2^47 (256-bit request), letting attackers brute-force any long-term secret produced by it. Downstream cryptocurrency wallets used this function as the entropy source for BIP39 recovery phrases; Coinspect's 'Ill Bloom' investigation reproduced full key recovery and documented coordinated drain waves that stole a lower-bound of ~$5M in assets as of 13 July 2026. This is not in CISA KEV, but a proof of concept exists and real-world theft has been documented by the researchers.
Technical ContextAI
The root cause is CWE-331 (Insufficient Entropy). Instead of a CSPRNG, crypto-js 3.1.2-4 through the 3.x line implemented a custom variant of George Marsaglia's Multiply-With-Carry (MWC) PRNG seeded from the non-cryptographic Math.random(), introduced in commit ff1f003 (June 2014) to address issue #7. Because Math.random() and the small MWC state carry far less entropy than the nominal bit-length requested, the true output space of WordArray.random() is only ~2^39/2^47. The affected component is the npm package pkg:npm/crypto-js, a very widely used pure-JavaScript crypto library. Crucially, applying PBKDF2, another KDF, or a hash after this generator cannot restore missing entropy - the ceiling is set by the generator's tiny state space. Version 4.0.0 replaced the routine with the platform-native CSPRNG (Node.js crypto.randomBytes / browser crypto.getRandomValues), as shown in patch commit b405ff5. A subtle supply-chain wrinkle: the weak generator was reverted in 3.3.0 as a 'breaking change', so projects pinned to the 3.x line could upgrade to newer 3.x releases and still carry the flawed code.
RemediationAI
Vendor-released patch: crypto-js 4.0.0 (fix commit b405ff597fb3ac76a7bdfbc72dca10ba1079b1d5), which swaps the MWC/Math.random() generator for native crypto.randomBytes / crypto.getRandomValues - upgrade to 4.0.0 or later and, where feasible, replace CryptoJS randomness entirely with the Web Crypto API or Node.js crypto module. Because 3.3.0+ reverted the fix, do not trust a 'newer 3.x' pin; audit direct, downstream, and transitive dependencies for any crypto-js < 4.0.0. The critical trade-off: upgrading does NOT heal already-generated secrets - determine the versions/time windows when WordArray.random() produced security-sensitive values, treat all such long-term secrets (keys, recovery phrases, tokens) as compromised, and rotate them. Wallet users must create a brand-new wallet with a freshly generated recovery phrase from a trustworthy source and migrate funds, and must never re-import the old phrase (importing it into updated software or a hardware wallet does not remediate it). Advisory: https://github.com/brix/crypto-js/security/advisories/GHSA-rg76-677x-56q9. Never enter a recovery phrase or private key into any checker - https://illbloom.org/ accepts only public addresses.
A vulnerability in the NuPoint Unified Messaging (NPM) component of Mitel MiCollab through 9.8 SP1 FP2 (9.8.1.201) could
FortiOS and FortiProxy contain an authentication bypass via the Node.js websocket module allowing unauthenticated remote
Denial of service against HTTP/2 server implementations allows remote unauthenticated attackers to exhaust server resour
Eval injection vulnerability in the internals.batch function in lib/batch.js in the bassmaster plugin before 1.5.2 for t
Flowise version 3.0.5 contains a remote code execution vulnerability in the CustomMCP node. The mcpServerConfig paramete
Node.js 8.5.0 before 8.6.0 allows remote attackers to access unintended files, because a change to ".." handling was inc
An issue was discovered in the node-serialize package 0.0.4 for Node.js. Rated critical severity (CVSS 9.8), this vulner
OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0.1h does not properly restrict processing of ChangeCiph
Directory traversal vulnerability in the st module before 0.2.5 for Node.js allows remote attackers to read arbitrary fi
Multiple SQL injection vulnerabilities in the Manage Accounts page in the AccountManagement.asmx service in the Solarwin
The JS-YAML module before 2.0.5 for Node.js parses input without properly considering the unsafe !!js/function tag, whic
The AES-NI implementation in OpenSSL before 1.0.1t and 1.0.2 before 1.0.2h does not consider memory allocation during a
Same weakness CWE-331 – Insufficient Entropy
View allSame technique Information Disclosure
View allVendor StatusVendor
SUSE
Severity: CriticalShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-54599
GHSA-rg76-677x-56q9