As reported by The Hacker News, security researchers at Coinspect have traced at least $5.7 million in cryptocurrency theft to a fundamental cryptographic weakness in CryptoJS.lib.WordArray.random() — a function that has shipped weak entropy for over a decade. This is not a novel zero-day. It is a compounding failure of library design, developer trust, and supply chain hygiene that has quietly undermined wallet security across five applications.

Security Impact: As reported by The Hacker News, security researchers at Coinspect have traced at least $5.7 million in cryptocurrency theft to a fundamental cryptographic weakness in CryptoJS.lib.WordArray.random() — a function that has shipped weak entropy for over a decade.

Why This Is a Bigger Problem Than It Appears

The instinct when reading this story is to frame it as a "crypto wallet" problem. That framing undersells the risk. CryptoJS is one of the most widely downloaded JavaScript cryptography libraries in existence, appearing in millions of web applications, browser extensions, Node.js backends, and mobile app bundles. Any application that relies on CryptoJS.lib.WordArray.random() for security-sensitive randomness — key generation, token creation, session identifiers, nonce generation — may be operating on a compromised entropy source.

The root issue is a classic one in cryptographic engineering: Math.random() is not a cryptographically secure pseudorandom number generator (CSPRNG). It was never designed to be. Its output is statistically uniform enough for simulations, games, or shuffling arrays — but it is predictable, often seeded with low-entropy values, and entirely unsuitable for generating secrets. When CryptoJS introduced this function and wired it to Math.random() as a fallback or primary source, it created a silent trust violation — developers importing a "cryptography" library reasonably assumed its randomness primitives were cryptographically sound.

The most dangerous vulnerabilities are the ones developers don't know to question. A function named inside a cryptography library carries an implicit guarantee of security that simply doesn't exist here.

The Attack Surface Is Broader Than Wallets

Coinspect's on-chain forensics focuses on wallet recovery phrase generation — BIP-39 mnemonics derived from weak entropy — because that's where the financial trail is visible and quantifiable. But consider the following additional attack surfaces where this same flaw could manifest:

The Attack Surface Is Broader Than Wallets
Encryption key generation: Applications using CryptoJS for AES or other symmetric encryption that derive keys through this RNG may be generating recoverable keys.
Token and session ID generation: Web applications using CryptoJS to produce authentication tokens or CSRF tokens may be vulnerable to prediction attacks.
Password salting and hashing pipelines: Any application where CryptoJS generates salts for password hashing is using substandard entropy.
Browser extensions: Extensions handling identity or credential data that bundle CryptoJS deserve immediate audit.

The "Ill Bloom" drain campaign demonstrates that adversaries actively fingerprint wallet generation logic for exploitable entropy weaknesses. This is not a theoretical attack — it is an operational criminal technique. The two-sweep structure Coinspect identified suggests a methodical, patient threat actor who first surveyed vulnerable wallets before executing coordinated drains.

The Supply Chain Dimension

CryptoJS has been in maintenance mode and effectively abandoned by its original author. It continues to exist in countless dependency trees not because developers actively chose it, but because it was chosen years or decades ago and never revisited. This is a textbook supply chain risk: a widely trusted artifact that has outlived active security stewardship. npm's download statistics for CryptoJS remain high not from new adoption, but from the sheer inertia of existing codebases. Organizations running SBOM (Software Bill of Materials) processes should treat CryptoJS as a flag for immediate review.

Shield53 Recommendations

For Developers and Engineering Teams

  • Audit all usage of CryptoJS.lib.WordArray.random() immediately. Search your codebase, bundled dependencies, and any vendored JavaScript files. Use tools like npm audit, Snyk, or Socket.dev to surface CryptoJS in your dependency graph.
  • Replace with a CSPRNG. In browser environments, use window.crypto.getRandomValues(). In Node.js, use crypto.randomBytes() from the built-in crypto module. These are standards-compliant, well-audited, and hardware-entropy-backed.
  • Do not patch around CryptoJS — migrate away from it. The library's maintenance status means future vulnerabilities will go unpatched. Consider alternatives such as the Web Crypto API directly, or libsodium.js for higher-level cryptographic operations.
  • If your application generates any long-lived secrets (keys, recovery phrases, signing material) using CryptoJS, treat those secrets as compromised and initiate rotation procedures.

For Wallet Applications and DeFi Developers

  • Conduct a full cryptographic audit of your wallet generation pipeline, including all bundled JavaScript dependencies.
  • Notify users proactively if your application may have used weak entropy for wallet generation. Provide clear migration guidance to new wallets.
  • Implement on-chain monitoring for unusual sweeping behavior from wallets generated during vulnerable periods.

For Security Teams and CISOs

  • Add CryptoJS to your SBOM watchlist and flag any version as requiring remediation review.
  • Prioritize entropy source validation in secure code review checklists — this class of vulnerability is systematically underweighted.
  • Consider threat hunting across browser extensions and internal tooling that may bundle CryptoJS for credential or token generation workflows.

The lesson here extends well beyond cryptocurrency. When a library carries the word "crypto" in its name, developers — and the organizations that employ them — deserve confidence that its randomness primitives meet cryptographic standards. That confidence was misplaced for twelve years. The cost, at minimum, is $5.7 million and counting.