Coinspect’s investigation into a long-standing randomness issue in CryptoJS weak RNG points to a clear and costly outcome: attackers were able to drain multiple crypto wallet applications by guessing recovery phrases derived from weak entropy. The blockchain security firm estimates that total losses reached a lower bound of roughly $5.7 million, based on two theft waves observed since late May.
The root cause centers on a function in the JavaScript cryptography library CryptoJS that was introduced more than a decade ago. While modern cryptography expects high-quality randomness to protect sensitive values, Coinspect reports that the affected code dramatically reduced the search space for possible phrases—making enumeration feasible even with ordinary hardware.
What exactly is the CryptoJS weak RNG problem?
The vulnerable generator identified by Coinspect is CryptoJS.lib.WordArray.random(). Wallet developers used its output as an entropy source when creating recovery phrases—the words users rely on to restore funds if they reinstall a wallet or move to a different device.
In a well-designed system, 128-bit and 256-bit entropy should produce search spaces of 2^128 and 2^256 possible outcomes. Coinspect found that the weak RNG effectively shrank those spaces to approximately 2^39 and 2^47. That reduction is the difference between “impossible to guess” and “guessable through targeted computation.”
Importantly, the impact is not reversible after the phrase is created. Coinspect notes that if a recovery phrase was generated from the vulnerable output, later steps such as hashing or PBKDF2 processing cannot restore the missing randomness. Upgrading to a patched library version does not “fix” phrases already generated with weak entropy.
Which wallet apps were affected?
Coinspect confirmed five applications that used the vulnerable function specifically as an entropy input for recovery-phrase generation. Some are discontinued and have no practical remediation path; others were reported to have released fixes.
- RRWallet: Discontinued. Coinspect says there is no fix.
- Bexo Wallet: Coinspect says the issue was fixed in version 20.1.0, but updated builds were not yet uploaded at the time of review.
- NanChat: Independently confirmed by Coinspect as affected before 1.3.0. Fixed in 1.3.0.
- Bitcoin Libre: Coinspect says fixed in version 4, released in July 2024.
- Milo: Discontinued. Coinspect says there is no fix.
Coinspect also explained that the earlier disclosure referenced the same five wallets without naming them. The firm emphasized that it cannot guarantee every vulnerable wallet was identified—some apps or extension versions may already have been removed from app stores or extension marketplaces.
Why patching isn’t enough for already generated phrases
One of the most critical takeaways from Coinspect’s report is simple: updates don’t retroactively secure old recovery phrases. If a phrase was produced by an affected wallet version, it stays guessable wherever it is imported.
That includes importing into other wallets, even hardware wallets. Coinspect’s guidance for impacted users is therefore more involved than “install the latest version.” If your phrase may have been generated through the vulnerable path, you likely need to create a new phrase securely and move funds to addresses derived from that new seed.
According to Coinspect, seeds generated by hardware devices and most current software wallets are not affected in the way described here—because the weak entropy source is not part of that generation process.
How attackers carried out the recovery-phrase attack
Coinspect reproduced the attack chain by taking the weak RNG outputs, converting them into BIP39 phrases, deriving wallet addresses from those phrases, and then checking whether any derived addresses matched data observable on public blockchains.
This approach matters because it shows the attack is not based on intercepting keys or exploiting a running wallet at the moment of use. Instead, it’s rooted in the predictability of phrases when the entropy source is flawed.
Coinspect further reports that the vulnerable RNG enabled two distinct drain waves. A sweep on May 27 reportedly took about $3.14 million across 431 accounts. A second run between May 30 and July 13 reportedly removed about $2.55 million from addresses linked to 522 seeds, including roughly $2.18 million USDT associated with one Tron-related account on July 4.
Estimated losses and where the analysis looked
To quantify impact, Coinspect analyzed 128- and 256-bit entropy and then tracked derived seeds and addresses across multiple chains. Coinspect states it identified around 2,114 seeds and related addresses tied to the affected wallet behavior across Bitcoin, Ethereum, Tron, Rootstock, and Polygon.
Combining the observed results, Coinspect estimates losses of $5,690,922 through July 13. The firm describes this figure as a lower bound, meaning additional theft could have occurred outside what it could confirm from public datasets and identified seeds.
Coinspect also suggests the affected population is likely in the thousands on EVM-compatible networks and Bitcoin, but it does not provide a wallet-by-wallet breakdown beyond the five confirmed applications.
How the weak code returned in the CryptoJS history
CryptoJS itself changed over time. Coinspect explains that a generator based on Multiply-With-Carry was seeded using Math.random() and was introduced as part of a release line that later reverted.
Releases 3.2.0 and 3.2.1 switched to native cryptographic randomness. However, 3.3.0 restored the weaker logic because the change was considered breaking for some developers. That means a project upgrading within the 3.x range could unintentionally move from a fixed behavior back into a vulnerable one.
Finally, Coinspect reports that 4.0.0 permanently restored native randomness in February 2020. Still, other ecosystems and forks could reintroduce the weak behavior.
Even having CryptoJS isn’t always enough to be vulnerable
One nuance in the public disclosure is that not every project depending on CryptoJS is exploitable. Coinspect reports that an application is affected only if it uses the vulnerable function to generate security-sensitive values. Simply carrying the dependency does not automatically expose recovery phrases.
Coinspect also notes that the advisory’s package metadata lists releases below 4.0.0 more broadly than the set of apps that actually use the vulnerable RNG path. In other words, version ranges can look wider than the practical attack surface because the vulnerable behavior depends on how developers use the library.
What NanChat users and others should do
Coinspect says that NanChat was the only named application (as of August 6) that had published a public advisory. Its guidance to users who created a wallet before v1.3.0 is to treat it as compromised and migrate.
NanChat version 1.3.0 includes a tool to generate a new seed and move funds. Coinspect reports the vulnerability was disclosed by its founder and CEO, Juliano Rizzo, on June 10, with a fix shipped two days later.
For other wallets that are affected, Coinspect advises users to consult official project channels for the current version and migration instructions. Because patches do not retroactively protect already-generated phrases, the practical remediation typically involves generating a new recovery phrase and moving assets.
How to check risk: what Coinspect’s checker can (and can’t) tell you
Coinspect’s public checker accepts wallet addresses rather than recovery phrases or private keys. If an address matches the firm’s datasets, coins tied to the same recovery phrase may be at immediate risk.
A negative result does not guarantee safety—it only indicates the address was not found in the currently published datasets. This limitation matters because recovery-phrase enumeration can affect multiple related addresses beyond what any single public dataset may contain at a given point in time.
Bottom line
The CryptoJS weak RNG issue shows how a subtle randomness flaw can become a direct attack vector when developers use predictable entropy for recovery phrase generation. Coinspect’s analysis attributes at least $5.7 million in drain activity to this weakness and confirms five wallet applications affected through this recovery-phrase path.
If you suspect your wallet phrase was generated by an affected version, the safest approach is to migrate: create a new recovery phrase using a trusted method and move funds accordingly. Updates may be necessary, but they are not sufficient for already-generated phrases.
Source: https://thehackernews.com/2026/08/cryptojs-weak-rng-behind-57-million-in.html
