How Cloudflare is staying ahead of the AMD vulnerability known as “Zenbleed”

AMD “Zenbleed” Flaw: What It Is and How Cloudflare Is Responding

Google’s Information Security Team has disclosed a vulnerability in AMD’s Zen 2 processor architecture, affecting everything from EPYC data center chips to Ryzen 3000 CPUs. Dubbed “Zenbleed,” the flaw can be exploited to siphon sensitive data—including encryption keys and login credentials—directly from the CPU. The attack currently requires the ability to execute native code on the target machine. While a browser-based remote exploit has not been demonstrated, the risk is real enough that we’re patching our entire fleet of affected servers with AMD’s microcode update. We’ve seen no signs of exploitation in the wild, but we’ll continue to watch for and report any attempts.

How the CPU Stores Data

To understand the attack, it helps to look at how a CPU processes data. The arithmetic logic unit (ALU) handles mathematical operations like addition and multiplication, driven by the CPU’s clock signal. Data arrives at the ALU through a hierarchy of storage: secondary memory, primary memory, cache, and finally CPU registers, which hold either 32 or 64 bits of information depending on the design.

Modern CPUs rely on Advanced Vector Extensions (AVX) to accelerate heavy computations such as data compression, image processing, and cryptography. AVX operates on 16 YMM registers, each 256 bits wide. These registers also store masks that filter vector components during operations. Software like the glibc library uses AVX instructions to speed up string functions—strlen, memcpy, memcmp—which often process passwords and other sensitive text.

The Attack Mechanics

The attack exploits speculative execution, a feature where the CPU guesses the outcome of branches and executes instructions ahead of time to improve performance. When the prediction is wrong, instructions are rolled back, but microarchitectural traces—such as cache states—can still be recovered via side channels. That is not what happens here, though.

The Zenbleed flaw is caused by a register not being properly zeroed under specific conditions. The attack begins by triggering the XMM Register Merge Optimization, which tracks XMM registers whose upper halves have been cleared. A mov instruction triggers register renaming, which maps logical registers to physical ones. Then, a mispredicted conditional branch causes the vzeroupper instruction—which zeroes the upper half of AVX registers—to be speculatively executed. When that instruction is rolled back, the register is left in an undefined state.

That undefined state can point to data from the physical register file of the same CPU core, which may hold information from other processes. In effect, this is like a use-after-free bug in the CPU. No side-channel is needed; the data can be read directly. The public proof-of-concept achieves a leakage rate of 30 kb/s per core.

Because the register file is shared by all processes on a physical core, an attacker could monitor sensitive data flowing between the CPU and other system components—credentials, keys, or anything else passing through the processor.

Mitigation and Timeline

Successful exploitation requires precise timing, which is difficult to achieve without running code natively on the machine. The vulnerability, tracked as CVE-2023-20593, initially received a CVSS score of 6.5, classifying it as Medium Risk.

The initial workaround involves modifying a model-specific register called DE_CFG, which prevents complex instructions like vzeroupper from being speculatively executed. AMD has also released a microcode update to address the issue.

We’re applying that microcode to every server in our fleet with a potentially affected Zen 2 processor. To date, we’ve observed no signs of attempted exploitation. Our monitoring remains active, and we’ll report any suspicious traffic or attacks we detect across our network.