BlueHat IL 2026 - Ezra Caltum, Anders Fogh - Life and death of a CPU bug

Had you ever wondered what happens when a CPU vulnerability is disclosed to the vendor? CPU is the foundation of computing. If CPUs are insecure the entire stack is insecure. Also CPUs are Hardware, with a published ISA and a set of features. Breaking compatibility is not an option. So – how do we do it? We will give a behind the scenes guided tour to the full cycle CPU security process, based on a vulnerability reported to us a few years ago (Plundervolt). As with every vulnerability, we need to validate where we are vulnerable. But unlike software, we need to understand what goes on below the software. If things were not hard enough, there are also multiple hardware configurations and CPU generations that need to be checked on. As these are physical devices, some „hacks“ were required to scale and automate. Afterwards – we need to evaluate the risk to make the appropriate mitigations – or enable path for defeature, when it effects sensitive flows. For example – certain vulnerabilities (like Plundervolt) are only mitigated for confidential computing, as kernel access is an attack requirement. Other vulnerabilities, we share suggestions and recommendations with operating systems and ecosystem partners on how to apply mitigations in code. And some vulnerabilities require a strong cooperation between Hardware and our Software partners. Then we will deep dive into the microcode patching process, it’s limitations and how we test, patch and validate mitigations. To close – we will share with you how we proactively work on this kind of issues – from simulation, fuzzing, directed tests and „hacking“ the infrastructure.