crypto-js is a JavaScript library of crypto standards.

CVE-2026-71851 affects the CryptoJS.lib.WordArray.random() function in crypto-js versions ≥ 3.1.2-4 and < 4.0.0. These versions use a custom Multiply-With-Carry PRNG seeded by Math.random() instead of a cryptographically secure source. Requests for 128 or 256 bits of randomness yield effective search spaces of only ~2^39 and ~2^47 possibilities respectively — trivially enumerable on commodity hardware. The fix landed in version 4.0.0 in February 2020, over six years ago. The library is now discontinued; NodeJS and modern browsers ship native crypto modules that supersede it entirely.

The vendor's CRITICAL/9.0 rating reflects the *worst-case* outcome — complete private key recovery when the function is used for wallet seed generation, as proven by the Ill Bloom campaign that drained $5.7 million from five crypto wallet apps. However, the CVSS vector's own AC:H already signals that exploitation requires specific conditions. For enterprise defenders managing 10,000 hosts, the real question is whether any internal or customer-facing application calls WordArray.random() to generate session tokens, API keys, or HMAC secrets. Merely depending on crypto-js 3.x in package-lock.json is not sufficient to be exploitable — the application must actively invoke the vulnerable function for security-sensitive output. This condition significantly narrows the exploitable population, making the CRITICAL label overweight for most enterprise environments.

Why this verdict

• Narrow trigger condition: The vulnerability requires the application to call CryptoJS.lib.WordArray.random() for security-sensitive values. Most crypto-js consumers use it for AES encryption or SHA hashing with externally-provided keys — the vulnerable function is not in the hot path for typical usage.
• Six-year-old fix: Version 4.0.0 shipped in February 2020. Any application still on 3.x has had over six years of remediation runway. This narrows the exploitable population to unmaintained or legacy codebases.
• Offline attack, not RCE: This is not a remotely-triggerable code execution flaw. The attacker must first obtain or observe the output of the weak PRNG, then perform offline brute-force enumeration. There is no shell, no lateral movement, no privilege escalation inherent to the vulnerability itself.
• Role multiplier: crypto-js is an npm library embedded in application code. It does not run on domain controllers, hypervisors, or network edge appliances. In *typical enterprise roles* (Node.js API servers, frontend builds), the blast radius is confined to the secrets generated by that single application — session tokens, API keys, or HMAC signing keys. The worst plausible high-value role is a backend service that generates authentication tokens for a customer-facing SaaS platform; compromise of those tokens could enable account takeover across the tenant. This outcome is serious but bounded to one application's trust boundary, not fleet-scale. For crypto wallet applications (a narrow but real deployment role), the blast radius is total fund loss — proven by $5.7M in Ill Bloom drains — but wallet apps represent a tiny fraction of enterprise crypto-js deployments.
• Active exploitation prevents MEDIUM: Despite all friction, Coinspect documented $5.7M in real losses. The attack tooling is public. If an enterprise app does use the vulnerable function, the exploitation cost is < $500 in cloud compute.

Why not higher?

The CRITICAL rating assumes every crypto-js 3.x installation is exploitable, but the advisory itself states that merely depending on the library is insufficient — the application must actively use WordArray.random() for secret generation. This is a narrow subset of the installed base. The vulnerability provides no RCE, no lateral movement, and no privilege escalation; it is a cryptographic weakness whose blast radius is bounded to the secrets generated by one application. The fix has been available for six years.

Why not lower?

Active in-the-wild exploitation is confirmed with $5.7M in documented losses. Public brute-force tooling makes exploitation accessible to low-skill attackers for < $500. The EPSS score of 0.00317 is low but does not account for the proven Ill Bloom campaign. With ~10M weekly downloads and 15,583 dependents, the probability that at least one application in a 10,000-host enterprise uses the vulnerable function for token or key generation is non-trivial. Already-generated weak secrets cannot be retroactively strengthened by upgrading — they must be identified and rotated.

1. Audit all applications for WordArray.random() calls — Run grep -r 'WordArray.random\|CryptoJS.lib.WordArray.random' . across all Node.js codebases and bundled assets. Any hit in a security-sensitive context (token generation, key derivation, nonce creation) is a confirmed exposure. Prioritize this audit within the noisgate mitigation SLA of 30 days.
2. Rotate all secrets generated by vulnerable code paths — If audit confirms WordArray.random() was used for session secrets, API keys, HMAC keys, or any authentication material, rotate those secrets immediately — upgrading crypto-js alone does not fix already-generated weak values. This is the most critical compensating control.
3. Pin or upgrade crypto-js to ≥ 4.0.0 or replace with native crypto — Since crypto-js is abandoned, the best path is replacing all usage with Node.js built-in crypto.randomBytes() or the Web Crypto API crypto.getRandomValues(). If immediate replacement is impractical, pin to 4.0.0. Deploy within the 30-day noisgate mitigation SLA.
4. Add SCA policy to block crypto-js < 4.0.0 in CI/CD — Configure Snyk, Socket.dev, or npm audit to fail builds that include crypto-js < 4.0.0. This prevents reintroduction via transitive dependencies.

Run this script on any host with Node.js installed to check whether a project's node_modules contains a vulnerable crypto-js version. Execute from the project root directory: bash check_cryptojs.sh /path/to/project. No elevated privileges required.

#!/usr/bin/env bash
# check_cryptojs.sh — Detect vulnerable crypto-js versions (CVE-2026-71851)
# Usage: bash check_cryptojs.sh /path/to/project
# Requires: node (any version), or just grep/jq

set -euo pipefail

PROJECT_DIR="${1:-.}"
RESULT="UNKNOWN"

if [ ! -d "$PROJECT_DIR" ]; then
  echo "ERROR: Directory $PROJECT_DIR does not exist."
  exit 2
fi

# Check for crypto-js in node_modules
PKG_JSON="$PROJECT_DIR/node_modules/crypto-js/package.json"

if [ ! -f "$PKG_JSON" ]; then
  # Also check lock files for transitive deps
  if grep -q '"crypto-js"' "$PROJECT_DIR/package-lock.json" 2>/dev/null || \
     grep -q 'crypto-js@' "$PROJECT_DIR/yarn.lock" 2>/dev/null; then
    echo "INFO: crypto-js found in lock file but not installed. Run npm install first."
    RESULT="UNKNOWN"
  else
    echo "PATCHED — crypto-js is not a dependency of this project."
    exit 0
  fi
else
  VERSION=$(node -e "console.log(require('$PKG_JSON').version)" 2>/dev/null || echo "")
  if [ -z "$VERSION" ]; then
    VERSION=$(grep '"version"' "$PKG_JSON" | head -1 | sed 's/.*"version".*"\(.*\)".*/\1/')
  fi

  if [ -z "$VERSION" ]; then
    echo "UNKNOWN — could not parse crypto-js version."
    exit 2
  fi

  echo "INFO: Found crypto-js version $VERSION"

  # Parse major version
  MAJOR=$(echo "$VERSION" | cut -d. -f1)

  if [ "$MAJOR" -ge 4 ] 2>/dev/null; then
    echo "PATCHED — crypto-js $VERSION is >= 4.0.0 (not affected by CVE-2026-71851)."
    exit 0
  else
    echo "VULNERABLE — crypto-js $VERSION is < 4.0.0 (affected by CVE-2026-71851)."
    # Additional check: see if WordArray.random is actually called
    echo ""
    echo "=== Checking for WordArray.random() usage in source code ==="
    HITS=$(grep -r -l 'WordArray\.random\|CryptoJS\.lib\.WordArray\.random' "$PROJECT_DIR/src" "$PROJECT_DIR/lib" "$PROJECT_DIR/app" 2>/dev/null | head -20 || true)
    if [ -n "$HITS" ]; then
      echo "WARNING: WordArray.random() calls found in application code:"
      echo "$HITS"
      echo ""
      echo "VULNERABLE — confirmed usage of the weak PRNG function."
    else
      echo "NOTE: No WordArray.random() calls found in src/lib/app directories."
      echo "VULNERABLE — version is affected, but exploitability depends on whether"
      echo "            WordArray.random() is called for security-sensitive generation."
      echo "            Check all code paths including bundled/transpiled files."
    fi
    exit 1
  fi
fi

echo "$RESULT"
exit 2

Sources

1. CVE-2026-71851 — CVEReports
2. GHSA-rg76-677x-56q9 — GitLab Advisory Database
3. CryptoJS Weak RNG Behind $5.7M in Drains — The Hacker News
4. crypto-js Weak Randomness in WordArray.random() — TheHackerWire
5. crypto-js — npm
6. crypto-js Security Analysis — Socket.dev
7. OffSeq Threat Radar — CVE-2026-71851