.webp)
Modern platform security integrates various components of contemporary infrastructure security, such as confidential computing and artificial intelligence (AI). Microcode has always been a crucial component in platform security for the x86 ecosystem. Any vulnerability in microcode leads to significant issues and long-standing side effects across the entire industry. Last week, we witnessed a rare instance of such a vulnerability highlighting potential gaps in AMD’s product security practices, prompting industry-wide discussion on the security implications for confidential computing.
The long-tail ramifications of this bug are obvious to anyone paying attention. The ability of an attacker to downgrade the microcode to an older vulnerable version effectively reintroduces vulnerabilities from previous versions. Microcode is very powerful because it runs at the microarchitecture level for x86 CPUs. For defenders, there are basically no options left once the microcode’s trusted boundaries or security features are compromised.
We’ve seen similar tactics before: attackers abusing vulnerable operating system drivers, compromised bootloaders like BlackLotus, and firmware components to reintroduce already patched vulnerabilities as new attack vectors. Microcode is no different. Updates can cause reliability issues and even performance hits (flashbacks from Specter microcode updates) and because there’s a documented way to roll them back, attackers can exploit this gap to revert systems to a vulnerable state.
This all started last week, when the Google security team released an advisory with partial documentation of a vulnerability (CVE-2024-56161) affecting AMD processors. The vulnerability affects the verification of the signature attached to microcode, meaning that any privileged attacker exploiting this vulnerability will be able to load malicious microcode.
Since the microcode controls the low-level operations of the CPU, this vulnerability has profound security implications and opens the door to a plethora of attacks. In practice, exploiting this vulnerability allows attackers to effectively alter the inner workings of a CPU. For example, the PoC microcode for Milan and Genoa AMD CPUs released by Google researchers alters the behavior of the rdrand instruction to always return 4.
AMD published a separate ‘high-severity’ security bulletin confirming the issue and providing mitigation guidance. The bulletin is focused on the impact of this vulnerability on AMD’s Secure Encrypted Virtualization (SEV), a technology used in cloud computing to increase the isolation and the confidentiality of virtual machine guests.
This vulnerability has implications for securing software supply chains. On the one hand, backdoored microcode updates delivered through a supply-chain attack become a technically feasible threat. On the other hand, OEMs will need to release UEFI BIOS updates to mitigate this issue.
Given our unique perspective on the UEFI ecosystem, we started monitoring the release of these updates. The first group of microcode updates we detected are targeting AMD EPYC CPUs, which are commonly used in servers and cloud environments. These findings align with the information shared by AMD in their advisory. The table below summarizes the updates we observed, including the target CPUID, revision number and release date (as found in the microcode update header).
The second set of updates apply to consumer CPUs belonging to the Ryzen family. The fact that consumer CPUs are also affected by CVE-2024-56161 has slipped under the radar, as the AMD advisory focuses only on mitigations for server CPUs.
However, it is highly likely that a significant portion of consumer CPUs (AMD Ryzen) are also affected. A key indication of this is that Google’s PoC explicitly mentions successful execution on an AMD Ryzen 9 7940HS CPU. Additionally, as shown in the table below, during our monitoring of the ecosystem we found some microcode updates targeting consumer CPUs which were released around the same time as their server counterparts.
Not many vendors have started releasing microcode updates patching CVE-2024-56161. As of the date of this blog, our telemetry data shows that only Dell, HPE, MSI, and ASUS have released UEFI updates to their customers. Nevertheless, only a small fraction of devices are covered by these updates, with more hopefully coming before the full details of this vulnerability are fully unveiled on March 5, 2025.
The Binarly Transparency Platform has full support for scanning microcode. Our platform can detect any security vulnerability related to microcode – like CVE-2024-56161 – but also when firmware contains outdated microcode.
.gif)
All told, CVE-2024-56161 highlights just how critical microcode security is for both servers and consumer systems. This bug is clear evidence of the far-reaching impact that compromised microcode can have, undermining even advanced features like SEV in data centers and exposing everyday Ryzen users to potential risk. While our Binarly Transparency Platform is tracking firmware updates rolling out, many affected devices remain unprotected and the long-tail ramifications will be severe.
Security solutions cannot do much to prevent microcode attacks since the format is undocumented and it’s difficult to track changes or provide any level of inspectability. It’s important for infrastructure security teams to understand when the most recent version of microcode is deployed and to be diligent about discovering and monitoring the device inventory for these attack vectors.
