Author:
Jerry Bryant, Intel Product Assurance and Security (IPAS)
Intel actively encourages and studies external security research aimed at compromising platform security. This includes research on Intel products as well as issues that potentially impact the broader ecosystem, as such work often exposes new attack techniques, assumptions, or failure modes that are broadly applicable. We systematically integrate these insights into our Security Development Lifecycle (SDL), strengthening platform defenses. This helps ensure our engineers are aware of state-of-the art attacks and directions in external security research.
The hardware platform represents the system root of trust, and hardware vulnerabilities are historically among the most difficult classes of issues to discover. They require specialized architectural knowledge and skill sets distinct from software security. This is reflected in our bug bounty data: in 2024, 84% of Intel bug bounty–eligible vulnerabilities were in software, with the remainder in firmware. While Intel mitigated 21 hardware vulnerabilities that year, all were discovered internally by Intel researchers.
Across new Intel products released since early 2023, only one externally discovered hardware side-channel issue required an update to an existing mitigation, underscoring the effectiveness of proactive security assurance. Over the same period, AMD* disclosed 10 externally discovered hardware vulnerabilities affecting its newest platforms.
Besides side channel vulnerabilities—which, while often high profile, are frequently impractical in real world threat models—we focused on research targeting foundational platform security assurances. These include attempts to break confidential computing isolation, compromise cryptographic boundaries, or escalate privilege into firmware domains such as System Management Mode (SMM). While researchers have demonstrated success against such guarantees on other platforms, no such issues have been discovered externally on Intel’s latest platforms.
To learn more about Intel platform security and our silicon industry leading product security assurance practices, check out the 2026 Intel Platform Security Report.
Vulnerability Analysis
The vulnerabilities we analyzed fell into the categories below. Importantly, while some of these issues affect Confidential Computing, the root causes exist in the system hardware and not the Confidential Computing firmware itself.
- Breaks Confidential Computing isolation (for example, virtual machine (VM) memory integrity during initialization).
- Compromises cryptographic foundations (entropy/seed integrity that cascades into key compromise).
- Escalates into firmware privilege domains (SMM compromise enables stealthy persistence).
- Allows persistent compromise via microcode/CPU update path (forged microcode → long-lived rootkits/bootkits).
- Enables control-flow hijack conditions in confidential workloads (microarchitectural state hazards that bypass isolation assumptions).
RMPocalypse – Root-of-Trust Race Condition (Confidential VM Memory Integrity)
What: A medium severity (CVSS 6.0) race condition in the AMD Secure Processor.
Impact: Allows a malicious hypervisor to corrupt the Reverse Map Table (RMP) during initialization, compromising the integrity of VM guest memory.
Details: The vulnerability centers on a component called the Reverse Map Table (RMP). This table is the "protector" of the system's memory. Its job is to ensure that only authorized programs can access specific data. Because the RMP is very large, it has to be stored in the main memory. To protect that memory, the system uses the RMP itself – but fails to fully protect it during initialization.
CWE-284 (Improper Access Control): The core of RMPocalypse is that the system fails to restrict "write" access to the Reverse Map Table (RMP) during its sensitive initialization phase. An unauthorized actor (the hypervisor) can modify data it should not be able to touch.
Analysis: During different parts of our product development process, Intel designs and implementations are carefully evaluated against a variety of common security weaknesses, including proper access control for sensitive content. Our assurance efforts include Formal Verification and Negative Space Testing, focusing on system interactions under normal operations as well as corner-case scenarios. This attention to detail helps ensure access control works as intended amid race conditions as well as power state transitions.
Who: Published October 2025 in a paper titled “RMPocalypse: How a Catch-22 Breaks AMD SEV-SNP” by researchers Benedict Schlüter and Shweta Shinde from ETH Zurick.
RDSEED – Silent Entropy Failure (Cryptographic Integrity Collapse)
What: A high-severity (CVSS 7.2) vulnerability in the RDSEED instruction on AMD platforms compromising the integrity of hardware-generated random numbers critical for cryptographic functions.
Impact: The "silent failure" prevents software from detecting hardware depletion, leading to the use of predictable values in security-critical operations. Systems relying on the affected RDSEED instruction may produce predictable or weak values, potentially allowing an attacker to infer sensitive information, compromise encryption keys, or bypass authentication mechanisms.
Details: This vulnerability is a microarchitectural defect in Zen 5* processors that incorrectly signals "success" (Carry Flag = 1) even when the internal entropy pool is exhausted. Specifically, under heavy system load, the 16-bit and 32-bit RDSEED instructions fail to detect entropy depletion and silently return non-random zeros as if they were valid cryptographic seeds.
CWE-333 (Improper Handling of Insufficient Entropy in TRNG): The core of the RDSEED vulnerability is a failed “Failure Signal,” leading to predictable output.
Analysis: Intel engineers ensure that error handling paths are carefully implemented and verified during robust functional validation and security testing. We work continuously to harden Intel® Secure Key technology. Intel’s recent Entropy Security Certification is a testament to its robust design conforming to NIST 800-90A/B/C, earning FIPS 140-3 and Common Criteria certifications.
Who: Discovered in 2025 by Gregory Price, a Linux* kernel engineer with Meta*.
SinkClose – SMM Privilege Escalation (Invisible Persistence Below the OS)
What: A high-severity (CVSS 7.2) SMM vulnerability (CVE-2023-31315) affecting AMD platforms dating back to 2006, including Ryzen*, EPYC*, and Threadripper* processors. SinkClose could allow a privileged attacker to escalate privileges into SMM.
Impact: Potential installation of persistent malware, such as bootkits and rootkits that survive reboots, OS reinstalls, or even firmware updates. Infections in SMM are nearly undetectable and could compromise system integrity below the OS level.
Details: This attack exploits a misconfiguration in AMD’s TClose configuration bit, which is supposed to redirect SMRAM memory accesses to normal DRAM during early firmware initialization. It was possible for an attacker to re-enable TClose after SMRAM is locked, and with that create their own code in DRAM at the SMM entry point address.
CWE-20 (Improper Input Validation): This is the primary classification, as AMD describes the root cause as "improper validation in a model-specific register (MSR)," which enables chained weaknesses like CWE-94 (Improper Control of Generation of Code) for arbitrary code execution in SMM.
Analysis: Intel recognized this space as a potential target for researchers and attackers over a decade ago and has implemented proactive product security assurance and security hardening efforts to safeguard our products. As a result, Intel is not affected by SinkClose.
Who: SinkClose was discovered by IOActive* security researchers Enrique Nissim and Krzysztof Okupski, who publicly disclosed it at DEF CON 32 (2024) in a talk titled “AMD SinkClose: Universal Ring-2 Privilege Escalation.” This follows a pattern of AMD SMM flaws, akin to the "Ghosts in the Machine Check" exploit (DEF CON 33, 2025), using Machine Check Exceptions for similar escalations.
EntrySign – Microcode Signature Verification Bypass (CPU Instruction Stream Trust Broken)
What: A medium severity (CVSS 6.4) vulnerability that allows an attacker to bypass AMD’s microcode signature verification mechanism on Zen 1 through Zen 5 processors. AMD used a 128-bit AES-CMAC with a secret key shared across CPUs. According to researchers, Zen 1 through Zen 4 used the example key of the NIST SP 800-38B publication, which allowed them to break the two usages of AES-CMAC and forge new public keys with the same hash as the authentic AMD key.
Impact: Potential for an attacker to forge valid microcode patches and installation of malware such as bootkits and rootkits that persist after reboots or OS reinstalls.
Details: While AMD used digital signatures (RSA) to authenticate microcode updates, the process relied on a cryptographic function that was not robust enough to prevent collisions or falsification.
CWE-327 (Use of a Broken or Risky Cryptographic Algorithm), CWE-321 (Use of hard-coded Cryptographic Key), and CWE-347 (Improper Verification of Cryptographic Signature) all apply to this issue.
Analysis: Intel uses recommended safe cryptographic hashes and securely generated and stored cryptographic keys to validate microcode patches and platform configurations.
Who: EntrySign was discovered and disclosed by Google* researchers Josh Eads, Kristoffer Janke, Eduardo’ Vela’ Nava, Tavis Ormandy, and Matteo Rizzo in March 2025.
StackWarp – Microarchitectural Control-Flow Desynchronization (Confidential VM Takeover Risk)
What: A low severity (CVSS 3.2) vulnerability, StackWarp is a microarchitectural vulnerability in AMD Zen-series CPUs that allows a malicious host to hijack a confidential VM’s control flow by exploiting a synchronization failure in the processor's stack engine.
Impact: An attacker could hijack control flow to redirect execution to arbitrary locations within the guest VM, bypass security checks to escalate privilege, or gain full control over the confidential VM through remote code execution.
Details: A virtual machine manager (VMM) or host is able to manipulate the stack pointer of virtual machines, due to the lack of synchronization of the CPU’s stack engine. This is an issue for threat models involving Hosts and VMMs outside of the trusted computing base (TCB) – for example, Confidential Computing.
CWE-1264: Hardware Logic with Insecure De-Synchronization between Control and Data Channels: This is the most accurate "root cause" CWE for StackWarp. It describes a failure where hardware logic (the stack engine) becomes out of sync with the intended state of the system (the architectural stack pointer).
Analysis: Intel’s microarchitecture does not share the same “deferral” logic or the specific thread configuration vulnerability found in AMD Zen microarchitecture. The Intel® Trust Domain Extensions (Intel® TDX) Module is architecturally required to save, scrub, and restore the entire CPU state (including general-purpose registers like the Stack Pointer) during every transition, aiming to ensure that no “stale” or “desynchronized” data from the host’s microarchitectural state can be exposed or otherwise affect the guest’s execution.
Who: StackWarp was discovered by Ruiyi Zhang, Tristan Hornetz, Daniel Weber, Fabian Thomas, Lukas Gerlach, and Michael Schwarz of CISPA, as well as Youheng Lü of SCHUTZWERK GmbH.
Conclusion
As the hardware security research landscape continues to advance, Intel’s product security assurance must evolve with it. Systematic analysis of confirmed vulnerabilities—including those observed outside Intel platforms—strengthens our understanding of emerging attack techniques and informs our platform-level threat models. This disciplined approach enables us to continuously sharpen our functional validation and security testing, reinforcing Intel’s leadership in delivering predictable, verifiable security assurance at scale.
Share Your Feedback
We want to hear from you. Send comments, questions, and feedback to the INT31 team.
About the Author
Jerry Bryant is the senior director, Incident Response and Security Communications in IPAS and the author of the Intel Platform Security report.