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, allowing local attackers to manipulate values to generate zeros non-randomly. The vulnerability was discovered by a Meta engineer in mid-October and already has Linux kernel patches available, though AMD states it wasn’t formally reported through their disclosure process. Microcode updates have started rolling out for Epyc 9005 “Turin” server processors, with consumer Ryzen 9000 series patches expected this month and embedded chip fixes coming by January 2026.
Sponsored content — provided for informational and promotional purposes.
The timing couldn’t be worse
Here’s the thing – AMD just launched their Zen 5 architecture as their flagship product line, positioning these chips as their most advanced and secure offerings. Now they’re dealing with a cryptographic vulnerability that fundamentally undermines trust in their hardware security features. The fact that patches won’t be fully deployed until January 2026 for some embedded systems is concerning. That’s over a year where certain devices could remain vulnerable unless workarounds are properly implemented.
The practical workarounds
AMD’s recommended fixes are actually pretty straightforward for technical users. You can switch to the 64-bit RDSEED version that’s not affected, disable RDSEED entirely through boot parameters, or just treat any zero returns as failures and retry. But here’s the catch – how many average users even know what RDSEED is, let alone how to configure boot parameters? This puts the burden on system administrators and OEMs to implement these changes properly. The real question is whether these workarounds will be consistently applied across the millions of devices running Zen 5 chips.
This isn’t AMD’s first rodeo
What’s really interesting is that this isn’t the first time AMD has faced RDSEED issues. Back in 2021, Zen 2-based “Cyan Skillfish” APUs had a similar problem where RDSEED would consistently return 0xffffffff instead of random numbers. Basically, we’re seeing a pattern where AMD’s hardware random number generators keep having critical flaws. That’s not great for a company trying to compete in security-conscious enterprise and data center markets. You’d think they would have learned from the previous incident and implemented more rigorous testing.
Why this matters beyond AMD
Look, hardware-based random number generation is supposed to be the gold standard for cryptographic security. When these fundamental building blocks fail, it shakes confidence in the entire security ecosystem. The fact that a Meta engineer found this rather than AMD’s own testing raises questions about whether chipmakers are investing enough in security validation. And with AMD’s security bulletin acknowledging the flaw affects both confidentiality and integrity, this isn’t some minor bug – it’s the kind of vulnerability that could have serious real-world consequences if exploited.
