GHSA-rg76-677x-56q9: Weak RNG

Published Aug 7, 2026
·
Updated

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:

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/

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.0 and 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

Affected Software

1 affected componentFixes available
npm/crypto-js<4.0.0
4.0.0

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade npm/crypto-js to a version that resolves this vulnerability.

    Fixed in 4.0.0
  2. Upgrade

    Upgrade crypto-js to a version that resolves this vulnerability.

    Fixed in 4.0.0
  3. Upgrade

    Upgrade crypto-js to a version that resolves this vulnerability.

    Fixed in 3.3.0
  4. Configuration

    Determine whether `CryptoJS.lib.WordArray.random()` was used to generate security-sensitive values (e.g., BIP39 recovery phrases). If so, where possible replace CryptoJS randomness with the native Web Crypto API or Node.js `crypto` module.

    CryptoJS CryptoJS.lib.WordArray.random() usage (entropy/PRNG source) = Replace with native Web Crypto API or Node.js crypto module
  5. Compensating control

    Use the Coinspect public address checker for addresses identified in the known Ill Bloom exposed-address datasets; treat matches as immediate risk (negative result only means the submitted address was not found in currently published datasets).

  6. Operational

    Treat all long-term secrets generated through an affected path as compromised and rotate them.

  7. Operational

    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.

  8. Operational

    For wallet users: do not import the existing recovery phrase into the new wallet (and do not enter a recovery phrase/seed phrase/mnemonic/private key/password/wallet backup file into any wallet application).

  9. Operational

    Audit direct, downstream, and transitive dependencies for versions of `crypto-js` matching `< 4.0.0`.

Event History

Aug 7, 2026
Advisory Published
via GitHub·06:48 PM
Data Sourced
via GitHub·06:48 PM
DescriptionSeverityWeaknessAffected Software
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of GHSA-rg76-677x-56q9?

GHSA-rg76-677x-56q9 has a critical severity rating of 9.

2

How do I fix GHSA-rg76-677x-56q9?

To fix GHSA-rg76-677x-56q9, update to a version of the CryptoJS library that addresses the weak random number generator issue.

3

What is the risk associated with GHSA-rg76-677x-56q9?

The risk associated with GHSA-rg76-677x-56q9 includes possible exposure of sensitive data due to inadequate randomness.

4

What types of systems are affected by GHSA-rg76-677x-56q9?

GHSA-rg76-677x-56q9 affects systems using vulnerable versions of the npm/crypto-js library.

5

What vulnerability class does GHSA-rg76-677x-56q9 belong to?

GHSA-rg76-677x-56q9 belongs to the CWE category of Weak Random Number Generator.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203