According to TechSpot, AMD has revealed a critical security vulnerability in its Zen 5 processors that compromises their hardware-based random number generator, potentially creating predictable encryption keys. Cataloged as AMD-SB-7055 and tracked as CVE-2025-62626, this high-severity flaw affects the RDSEED instruction in 16-bit and 32-bit forms. The vulnerability was discovered by a Meta engineer in mid-October and wasn’t formally reported through AMD’s coordinated disclosure process. AMD has already released microcode updates for Epyc 9005 “Turin” processors and expects patches for consumer Zen 5 chips later this month. The company plans to complete security fixes for all affected processors, including embedded chips, by January 2026.
Sponsored content — provided for informational and promotional purposes.
Why This Is a Big Deal
Here’s the thing about random number generators – they’re the foundation of modern encryption. When they stop being random, everything built on top becomes vulnerable. This particular flaw doesn’t just generate weak randomness – it can actually return zero values while telling the system everything worked perfectly. That’s like having a lock that sometimes doesn’t actually lock, but the door still makes a clicking sound so you think you’re safe.
And this isn’t some theoretical risk. We’re talking about encryption keys that could contain predictable patterns, which basically defeats the entire purpose of encryption. Local attackers could potentially manipulate these values to weaken security systems. The fact that systems can’t even verify whether the numbers are truly random makes this particularly dangerous.
AMD’s History With RDSEED Issues
This isn’t even the first time AMD has had problems with RDSEED. Back in 2021, Zen 2-based “Cyan Skillfish” APUs had a similar issue where RDSEED would always return 0xffffffff instead of random numbers. So we’re looking at a pattern here – different generations, similar problems with the same instruction.
What’s concerning is that these flaws keep appearing in what should be rock-solid hardware security features. You’d think after the first incident, there would be more rigorous testing around these critical components. But apparently not.
What You Should Do Now
If you’re running Zen 5 hardware, AMD has provided some immediate workarounds while waiting for official patches. The simplest fix is to switch to the 64-bit version of RDSEED, which isn’t affected by this vulnerability. You can also disable RDSEED capability entirely using specific boot parameters.
Another temporary solution is to treat any zero values returned by RDSEED as failures and retry until you get a non-zero result. It’s not elegant, but it works. For Linux users, the kernel community has already released patches that disable RDSEED on Zen 5 systems.
The bigger question is whether these recurring issues with AMD’s hardware security features should make us rethink our trust in these components. When the foundation of your encryption can’t be reliably trusted, what does that say about the overall security posture? AMD’s official security bulletin provides more technical details, but the pattern here is hard to ignore.
