CVE-2025-62626: AMD CPU RDSEED Entropy Vulnerability

CVE-2025-62626 Overview

CVE-2025-62626 is an insecure random number generation flaw in AMD CPUs. The vulnerability stems from improper handling of insufficient entropy in the hardware RDSEED instruction. A local attacker with low privileges can influence the values returned by RDSEED, causing software to consume insufficiently random values. Applications that rely on RDSEED for cryptographic key generation, nonces, or session tokens may produce predictable outputs. The weakness is tracked under CWE-333 (Improper Handling of Insufficient Entropy in TRNG). AMD documents the issue in AMD Security Bulletin #7055.

Critical Impact
Cryptographic operations seeded by RDSEED on affected AMD CPUs may produce predictable outputs, undermining confidentiality and integrity of keys, tokens, and nonces generated on the host.

Affected Products

AMD CPUs listed in AMD Security Bulletin #7055
Software and operating systems that consume RDSEED output directly for cryptographic entropy
Virtualization workloads on affected hosts that expose RDSEED to guests

Discovery Timeline

2025-11-21 - CVE-2025-62626 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-62626

Vulnerability Analysis

The RDSEED instruction is designed to return non-deterministic, cryptographically-quality random values sourced from an on-die hardware entropy source. Software relies on the CPU to signal failure through the carry flag (CF=0) when the entropy pool is depleted. On affected AMD CPUs, insufficient entropy is not properly handled, so RDSEED can return values that a local attacker is able to influence. Callers that trust the returned value without additional whitening or health checks may seed their PRNGs with attacker-influenced data. The result is a weakening of any cryptographic material derived from that seed, including symmetric keys, asymmetric key pairs, IVs, and session identifiers.

Root Cause

The root cause is [CWE-333]: improper handling of insufficient entropy in the true random number generator (TRNG). The instruction's success signaling does not fully reflect the entropy quality of the value delivered, allowing degraded output under specific local conditions described in AMD's advisory.

Attack Vector

Exploitation requires local access with low privileges and some attack complexity. No user interaction is needed. An attacker running unprivileged code on the same physical CPU can create conditions that reduce entropy quality, then observe or predict values consumed by a victim process. Guest-to-host and cross-VM scenarios are relevant where RDSEED is exposed to untrusted tenants. Technical details are available in AMD Security Bulletin #7055.

Detection Methods for CVE-2025-62626

Indicators of Compromise

Cryptographic artifacts (keys, nonces, session IDs) with low entropy or observable statistical bias
Duplicate or near-duplicate random values across independent processes or VMs on the same host
Unexpected authentication or key-agreement failures caused by predictable material

Detection Strategies

Inventory hosts against the AMD CPU models listed in AMD Security Bulletin #7055 and flag missing microcode updates
Audit software components that call RDSEED directly rather than using OS-provided CSPRNGs such as getrandom(2) or BCryptGenRandom
Run FIPS 140-3 style continuous health tests (repetition count and adaptive proportion) on any entropy source used for keying

Monitoring Recommendations

Monitor microcode and firmware versions across the fleet and alert on drift from AMD's fixed revisions
Track process-level use of RDSEED/RDRAND with EDR telemetry where available and correlate with cryptographic workload hosts
Collect and centralize CPU vendor advisories and microcode release notes in the SIEM for change tracking

How to Mitigate CVE-2025-62626

Immediate Actions Required

Apply the microcode and BIOS/UEFI updates referenced in AMD Security Bulletin #7055 as vendors release them
Restrict local code execution on affected hosts, particularly on multi-tenant and virtualization platforms
Prefer OS-provided CSPRNGs (getrandom, /dev/urandom, BCryptGenRandom) which mix multiple entropy sources rather than trusting RDSEED output alone

Patch Information

Refer to AMD Security Bulletin #7055 for the authoritative list of affected processors and the corresponding microcode revisions. Distribute updates through platform vendor BIOS/UEFI releases and hypervisor microcode loading mechanisms.

Workarounds

Disable direct exposure of RDSEED to untrusted guests where the hypervisor permits
Configure cryptographic libraries to combine RDSEED output with additional entropy sources using an extractor or KDF before use
Enable kernel entropy accounting and reject RDSEED values when hardware health tests fail

bash

# Configuration example: prefer kernel CSPRNG over direct RDSEED on Linux
# Verify getrandom() is available and used by applications
grep -r "RDSEED\|rdseed" /etc/ /usr/lib/ 2>/dev/null

# Check current microcode revision on AMD hosts
dmesg | grep -i microcode
cat /proc/cpuinfo | grep -E "model name|microcode" | sort -u