Weak RNG in CryptoJS Library Enables $5.7 Million in Crypto Wallet Drains

Coinspect's on-chain analysis puts the measured theft across two sweeps since late May at a lower bound of roughly $5.7 million.

CryptoJS.lib.WordArray.random() and its history

Blockchain security firm Coinspect identified CryptoJS.lib.WordArray.random() as the weak random number generator that produced insufficient entropy for recovery-phrase generation in multiple wallet apps. The weakness traces to a Multiply-With-Carry generator seeded from Math.random() that arrived in June 2014. CryptoJS releases 3.2.0 and 3.2.1 briefly switched to native cryptographic randomness, but release 3.3.0 restored the weaker code because the change was considered breaking; version 4.0.0 restored native randomness permanently in February 2020.

Coinspect also flagged a React Native fork, ferrumnet/bip39, which replaced upstream bip39's native cryptographic randomness with CryptoJS, as one route into wallet software. The CryptoJS maintainer, Evan Vosberg, published advisory GHSA-rg76-677x-56q9 on August 5 with a Critical rating and a CVSS score of 9.0. The advisory’s package field lists every release below 4.0.0, despite the 3.2.0 and 3.2.1 exceptions; it warns that an application is affected only if it uses the vulnerable function to generate security-sensitive values.

Five vulnerable wallets: RRWallet, Bexo, NanChat, Bitcoin Libre, Milo

Coinspect confirmed five applications that used the generator as an entropy source for recovery-phrase generation:

• RRWallet — described by Coinspect as discontinued; no fix.
• Bexo Wallet — reported fixed in version 20.1.0 by Coinspect, although updated builds had not yet been uploaded at the time of review.
• NanChat — independently confirmed that versions before 1.3.0 were affected; fixed in 1.3.0.
• Bitcoin Libre — reported fixed in version 4, released July 2024.
• Milo — described by Coinspect as discontinued; no fix.

Coinspect told The Hacker News these are the same five wallets it referenced without naming in July. The firm cautioned it cannot confirm it identified every vulnerable wallet; other affected mobile or browser-extension wallets may have existed but could not be examined because they had been removed from stores or replaced with patched releases.

On-chain findings: ~$5.69 million traced across two drain waves

Coinspect measured two exploitation sweeps. A May 27 sweep took about $3.14 million from 431 accounts. A second run between May 30 and July 13 took $2.55 million from addresses tied to 522 seeds, including roughly 2.18 million USDT from one Tron account on July 4. Together, later analysis tracked 2,114 identified seeds and associated addresses across Bitcoin, Ethereum, Tron, Rootstock, and Polygon, putting measured losses at $5,690,922 through July 13. Coinspect describes that figure as a lower bound.

Technically, Coinspect analyzed both 128‑ and 256‑bit entropy scenarios. While those should yield search spaces of 2^128 and 2^256, the vulnerable generator reduced them to roughly 2^39 and 2^47 — small enough to enumerate on ordinary hardware. Coinspect reproduced the attack chain by enumerating generator outputs, converting them into BIP39 phrases, deriving addresses, and checking them against public blockchain data.

Practical impact for users and remediation steps reported

Coinspect and The Hacker News emphasize that updating an app does not repair existing recovery phrases. A recovery phrase generated by a vulnerable version remains guessable wherever it is imported, including into a hardware wallet; subsequent hashing or PBKDF2 processing cannot restore the missing entropy, nor can a later package update.

Practical guidance and vendor actions reported in the sources include:

• NanChat published an advisory telling users who created a wallet before v1.3.0 to consider it compromised and migrate; version 1.3.0 includes a tool to generate a new seed and move funds. Coinspect founder and CEO Juliano Rizzo reported the issue on June 10 and the fix shipped two days later.
• Bexo’s 20.1.0 fix was reported as not platform-specific, but The Hacker News found that as of August 6 updated builds were not clearly available in public app listings: Apple’s App Store showed version 18.3.5 as the current iPhone release, and Google Play showed an Android update on May 20 without a public version number.
• Coinspect’s public checker accepts wallet addresses (not recovery phrases or private keys); a match indicates assets tied to the same phrase may be at immediate risk, while a negative result indicates the address is not present in the currently published datasets.

What this means for technologists, end users, and wallet maintainers

• Technologists and security teams: pay attention to transitive dependencies and forks — Coinspect identified ferrumnet/bip39 as one route into apps — and audit builds to ensure native cryptographic randomness is used where security values are generated.
• End users: any recovery phrase created using vulnerable paths should be treated as compromised; creating a new seed securely and moving funds is necessary because later updates do not restore lost entropy.
• Wallet maintainers: publishing a patched version is necessary but not sufficient; Coinspect cautioned that older vulnerable builds can remain extant and that an upgrade within the 3.x line could reintroduce the weakness if a project moved from a fixed release back to a vulnerable one.

Coinspect withheld technical details for two months while notifying vendors and searching for exposed addresses; the public disclosure and the CryptoJS advisory together aim to limit further exploitation while giving projects time to remediate. For current checks and vendor guidance, Coinspect advised users to consult projects’ official channels. Read the original report on The Hacker News: https://thehackernews.com/2026/08/cryptojs-weak-rng-behind-57-million-in.html