Coinspect researcher Ill Bloom has traced a lower-bound of roughly $5.7 million in stolen cryptocurrency to a weak random number generator in the widely used CryptoJS library. The vulnerable function, CryptoJS.lib.WordArray.random(), has been in the library for about 12 years and underpins key or address generation in five identified wallet applications, making the theft a supply-chain failure as much as an attacker’s success.
The Twelve-Year-Old Weak RNG Inside CryptoJS
The vulnerable routine is CryptoJS.lib.WordArray.random(), a random-number function that has been present in the library for approximately 12 years. Predictable keys or addresses generated with the weak RNG allowed attackers to derive or match wallet addresses and drain funds. Because CryptoJS is a ubiquitous JavaScript library, the flawed function reaches any application that relied on it for security-sensitive randomization.
The Five Affected Wallet Apps and Their Patch Status
The five affected applications are RRWallet and Milo, both discontinued with no fix available; Bexo, fixed in version 20.1.0; NanChat, fixed in version 1.3.0; and Bitcoin Libre, fixed in v4. Users of the discontinued apps have no vendor update to rely on and should move funds to a wallet with secure key generation.
How a Weak Random Generator Becomes Wallet Drain
Wallet security depends on generating keys that cannot be predicted. When a wallet derives an address from a weak RNG, an attacker who understands the entropy limitations can derive or match the address, then move the funds. The observed thefts are split across two separate sweeps, together accounting for the roughly $5.7 million figure.
Why the CryptoJS RNG Matters Beyond the Five Named Apps
The significance of the finding extends beyond the named applications because the flawed function is inside a general-purpose library. Any wallet or application built on CryptoJS’s insecure randomization is potentially at risk of key recovery, and the five identified apps are the known casualties rather than the full universe of exposure. The library ecosystem should be monitored for downstream dependents that carry the same weakness.
What the CryptoJS Findings Mean for Wallet and App Developers
For developers, the finding shows that security-sensitive randomness must come from a platform-backed source, not from a general-purpose utility. Wallet applications must migrate to cryptographically secure randomness such as the Web Crypto API’s getRandomValues, and audit any code path that used the library for key generation.
Moving Funds and Auditing Key Generation for Affected Users
Users of the five named apps should move funds to hardware wallets or to applications with secure key generation, and treat any addresses generated through the vulnerable path as exposed. The two observed theft sweeps suggest the attackers were systematic, deriving addresses across the affected apps rather than exploiting an individual user’s mistake.
The CryptoJS case shows that weak cryptography can linger for over a decade inside a library that most developers consider safe, and that the failure surfaces only when real money is drained. Because the vulnerable function shipped as part of a mainstream toolkit, the incident is less a targeted attack than a consequence of trust placed in a library without reviewing its randomness quality. For the broader ecosystem, the lesson is that key generation is not a place to accept a convenient default: randomness that decides wallet ownership must be cryptographically secure by construction, not by reputation.
The finding also shows why supply-chain hygiene matters for cryptocurrency tools specifically. Once a wallet address is derived from predictable entropy, no endpoint security product on the user’s device can undo the exposure, because the private key itself is computable from the weak random data. That makes the failure different in kind from a credential-leaking bug, and it is permanent for wallets that cannot be migrated to a secure implementation. It also shapes the incident’s long-term significance: apps such as RRWallet and Milo that are discontinued and unpatched leave every legacy wallet they generated at continuing risk, so the security of funds does not wait on a vendor release; users must act. For the wider developer community, the durable lesson is to treat the source of randomness as an attack surface worth the same review given to encryption and key-storage code.
