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. The flaw, cataloged as AMD-SB-7055 and tracked as CVE-2025-62626, affects the RDSEED instruction and is classified as High Severity. A Meta engineer discovered the issue in mid-October, and AMD has already begun rolling out microcode updates for Epyc 9005 “Turin” processors. Patches for consumer Zen 5 chips including Ryzen 9000 series and Threadripper 9000 are expected later this month, while embedded chip fixes won’t arrive until January 2026. The vulnerability specifically affects 16-bit and 32-bit RDSEED instructions, potentially forcing them to generate zeros instead of random values.
Sponsored content — provided for informational and promotional purposes.
Why This Is Actually a Big Deal
Here’s the thing about random number generators – they’re the foundation of everything secure in computing. When you generate encryption keys, create secure connections, or even just need truly unpredictable values, you’re relying on these systems. And when they fail, everything built on top becomes suspect. The fact that this flaw could make RDSEED return zeros instead of random numbers? That’s catastrophic for cryptographic security. Basically, you might think you’re creating a super-secure encrypted connection, but an attacker could potentially predict your keys because they know you’re getting predictable zeros.
What makes this particularly concerning is that the system might not even know it’s failing. AMD notes the bug may incorrectly signal failures as successes, so your software could be happily using compromised random numbers without any warning. It’s like having a broken smoke detector that tells you everything’s fine while your house is on fire.
AMD’s Rocky History With Random Numbers
This isn’t even the first time AMD has had issues with RDSEED. Back in 2021, Zen 2-based “Cyan Skillfish” APUs had a similar problem where RDSEED would always return 0xffffffff instead of random values. So we’re seeing a pattern here with AMD’s hardware random number generators. Now, to be fair, every chipmaker has security vulnerabilities – Intel has had its share of Spectre and Meltdown issues. But when the same component keeps having problems across multiple generations, it makes you wonder about their quality control processes for cryptographic hardware.
The timing isn’t great either. AMD is trying to compete aggressively with Intel in both consumer and server markets, and security concerns can seriously damage that momentum. Enterprise customers especially don’t want to hear that their shiny new Epyc servers might have cryptographic weaknesses.
What You Should Do Right Now
If you’re running Zen 5 hardware, there are immediate steps you can take. AMD recommends switching to the 64-bit version of RDSEED, which isn’t affected by this vulnerability. You can also disable RDSEED capability entirely using the clearcpuid=rdseed boot parameter. And importantly, treat any zero values returned by RDSEED as failures and retry until you get non-zero results. The Linux community has already patched this by disabling RDSEED on Zen 5 systems, so make sure you’re running updated kernels.
For most home users, the risk is probably lower than for data centers and enterprise environments. But if you’re doing anything that requires strong cryptographic security – which these days is basically everything – you’ll want to pay attention to those microcode updates as they roll out. AMD’s security bulletin has the detailed technical information if you need it.
The Bigger Picture
This situation highlights a recurring challenge in the chip industry – the tension between performance and security. Hardware random number generators are supposed to be faster and more secure than software alternatives, but when they fail, the consequences are severe. And we’re seeing these kinds of fundamental hardware flaws pop up with concerning frequency across all chipmakers.
What’s interesting here is that the vulnerability wasn’t formally reported through AMD’s coordinated disclosure process. A Meta engineer found it and the Linux community basically forced AMD’s hand by releasing their own patch. That suggests there might be some gaps in AMD’s internal security testing, or at least in how they’re coordinating with external researchers.
Looking ahead, this could temporarily slow AMD’s momentum in the server market where security is absolutely critical. But the company appears to be responding reasonably quickly with patches. The real test will be whether they can prevent similar issues in future architectures, because trust in hardware security is something you can’t afford to lose twice.
