Critical Security Flaws Discovered in AMD SEV-SNP Architecture Expose Confidential Virtual Machines to Host-Level Attacks
The cybersecurity landscape has been shaken by the public disclosure of two sophisticated attack vectors targeting AMD EPYC server processors. Made public this week, these vulnerabilities undermine the foundational security of AMD Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP), a flagship technology designed to bring confidential computing to enterprise cloud infrastructure. SEV-SNP was engineered to isolate virtual machines (VMs) so thoroughly that even the underlying hypervisor—the host operating system or virtual machine monitor managed by cloud providers—cannot access, read, or manipulate guest memory or execution states. However, the newly uncovered vulnerabilities, tracked as Mior and Skyfall, demonstrate that determined actors with specific administrative privileges can bypass these hardware-enforced protections.
The disclosure highlights the escalating complexity of securing modern silicon architectures, where hardware-based isolation must continuously contend with deep-seated firmware, boot-process manipulation, and side-channel leakage. While both attacks require privileged access at the host level, their potential to compromise confidential computing workloads has forced chipmaker AMD, server original equipment manufacturers (OEMs), and cloud service providers into a coordinated remediation effort.
An Anatomy of the Mior Attack Vector
The first and more structurally severe of the two disclosures, designated as Mior, was brought to light by a team of security researchers from ETH Zurich. Mior is a boot-time attack that specifically targets the initialization phase of AMD SEV-SNP. During a secure boot sequence, a dedicated and isolated microcontroller embedded within the processor chip—known as the Platform Security Processor (PSP)—is responsible for establishing the system’s integrity. Among its primary tasks, the PSP constructs and populates a critical data structure called the Reverse Map Table (RMP). The RMP functions as an absolute ledger within hardware memory, recording the ownership status of every physical memory page and dictating the precise access rights permitted for each page.
In their laboratory demonstrations on an AMD EPYC 9135 processor belonging to the Zen 5 architectural family, the ETH Zurich researchers engineered a way to intercept and manipulate this critical initialization phase. By wielding administrative control over the server’s host hypervisor and its Basic Input/Output System (BIOS)—more formally known as the Unified Extensible Firmware Interface (UEFI)—the attackers altered the hardware’s memory-routing configurations.
Specifically, the team redirected the PSP’s write operations during the boot sequence away from main system memory and toward a controlled Peripheral Component Interconnect Express (PCIe) device, such as a dedicated graphics processing unit (GPU). Anticipating that the PSP would attempt to read back these initialization values to verify their integrity, the rogue PCIe device successfully fed the expected data back to the processor. Consequently, the system’s start-up sequence concluded without throwing any error flags or triggering a security panic.
Beneath the surface, however, a portion of the real RMP—including the specific entry tasked with protecting the table itself—remained uninitialized. This glaring gap in the memory protection ledger granted the malicious hypervisor the ability to dynamically rewrite the RMP’s access controls. Once this barrier was removed, the research team enabled debugging features on a confidential virtual machine that had explicitly been configured with debugging disabled. Leveraging the PSP’s native debugging commands, the attackers successfully read and wrote arbitrary data directly into the VM’s protected memory space. According to the research group, this exploit achieved a 100% success rate across 1,000 consecutive test attempts.
Furthermore, the Mior attack extends its reach to the architectural attestation mechanisms that verify a VM’s software integrity upon booting. SEV-SNP relies on the PSP to generate cryptographic attestation reports signed with hardware-backed keys, proving to a remote challenger that the VM is running authentic, unmodified code. In a secondary demonstration, the ETH Zurich team copied the cryptographic measurement profile of a harmless, standard VM and mapped it onto a malicious VM. The PSP dutifully signed attestation reports for the compromised instance, certifying that it was running the benign workload while malicious code executed underneath.
Understanding the Skyfall Side-Channel Threat
While Mior requires complex manipulation during the boot phase involving both the hypervisor and the BIOS, the second disclosure—dubbed Skyfall—takes a distinctly different approach. Developed collaboratively by a separate team of researchers from ETH Zurich and Google, Skyfall builds directly upon Transient Scheduler Attacks (TSA), a class of microarchitectural vulnerabilities first disclosed in July 2025 that exploit instruction timing to leak sensitive data from processor caches.
Skyfall operates during the virtual machine instantiation phase. When a host hypervisor intentionally induces a fault that causes a VM to fail its start-up sequence, the processor has already populated parts of the VM’s initial state into internal hardware caches. Under normal operating conditions, these residual cache lines are purged or sanitized. However, due to architectural quirks exposed by Skyfall, remnants of this saved state are left behind without proper cleanup. A malicious host can subsequently leverage TSA techniques to peer into these leftover execution traces.
In their practical demonstrations, the research team successfully recovered critical VM operational data, including saved register values and a full disk-encryption key. To extract the encryption key, the researchers modified the test VM’s kernel to deliberately pause execution at the exact moment the key was loaded into processor registers. In a real-world scenario, an attacker would not need kernel cooperation; they could instead utilize a technique known as SEV-Step, single-stepping through the VM’s instructions until the target data surfaces in accessible registers.
Despite its potency, Skyfall does have operational constraints. The vulnerability does not grant sweeping read access to an entire memory page; rather, it allows an attacker to harvest specific data residing at three fixed cache line offsets within a targeted page (specifically at offsets 0x0c0, 0x380, and 0x3c0). The remainder of the page remains shielded by encryption. Moreover, the attack does not require any physical hardware tampering; it can be executed entirely through software provided the attacker maintains control over the host hypervisor. The research team successfully tested Skyfall across older and current hardware generations, including EPYC 7313 (Zen 3) as well as EPYC 9124 and EPYC 9334 (Zen 4) processors, though the leak vector was notably absent on Zen 5 chips.
Beyond standard virtual machine boundaries, the Skyfall research team discovered that the underlying principles could be weaponized to read decrypted microcode updates across all tested chip architectures. They also managed to recover sensitive register values stored within System Management Mode (SMM), a highly privileged operating mode executed below the operating system kernel that is normally completely inaccessible to host software.
Impact Assessment, Industry Response, and Patch Management
The public revelation of Mior and Skyfall has prompted an immediate, multi-layered response from AMD and the broader server ecosystem. Because confidential computing is heavily relied upon by financial institutions, government agencies, and enterprise cloud tenants to protect sensitive workloads from untrusted cloud operators, any flaw undermining this trust model is treated with maximum urgency.
AMD has officially cataloged the vulnerabilities within its product security bulletin database. Mior has been designated as CVE-2026-0462, carrying a CVSS 4.0 severity rating of 5.9. The vulnerability is strictly confined to processors utilizing the SEV-SNP architecture; legacy implementations such as SEV and SEV-ES remain unaffected. Meanwhile, the VM register data leak associated with Skyfall is tracked as CVE-2026-40671 with a CVSS score of 4.9. A related SMM memory leak discovered by the Skyfall team has been assigned CVE-2026-18448 with a severity rating of 5.6 by the EDK II firmware project.
To counter these threats, AMD has released updated firmware packages. Initial SEV firmware patches for Mior and microcode updates for Skyfall were distributed to server manufacturers on August 12. However, because these flaws are deeply intertwined with platform boot routines and low-level system architecture, complete mitigation requires comprehensive updates to platform firmware (UEFI/BIOS) supplied by individual server vendors.
According to AMD’s deployment roadmap, platform firmware updates addressing both Mior and Skyfall across major EPYC processor families—including the Milan (7003), Genoa (8004/9004), and Turin (8005/9005) series—are scheduled for staggered rollouts. Skyfall platform firmware patches are slated for release in November, while comprehensive Mior platform firmware updates are targeted for December. Fixes for embedded EPYC variants and specialized accelerators, such as the Instinct MI300A, are mapped out across late 2026 and early 2027.
Server vendors have begun reacting to the disclosures. Supermicro, for instance, has published preliminary security advisories and BIOS fix lists covering dozens of its H12, H13, and H14 motherboard configurations. However, the manufacturer noted that applying these fixes requires parallel updates to Baseboard Management Controller (BMC) firmware, and validation testing across diverse product lines remains ongoing.
Broader Implications for Cloud Tenants and Confidential Computing
The discovery of Mior and Skyfall underscores a persistent architectural challenge in the realm of secure hardware: the inherent trust placed in the boot chain. In the threat model defined for AMD SEV-SNP, AMD explicitly assumes that the UEFI/BIOS environment can be untrusted or potentially malicious, which is precisely why hardware-based memory encryption was implemented to fence off the hypervisor. However, the Mior exploit proves that if an attacker manages to compromise the initial transition phase before the hardware security co-processor fully locks down the system memory management structures, the entire security perimeter can be unraveled from within.
For enterprise customers who rent confidential virtual instances from public cloud providers, these findings introduce significant operational complexities. Because the necessary mitigations are implemented at the host firmware and microcode levels, cloud tenants have no direct ability to patch the underlying physical hardware. Instead, they are entirely dependent on their cloud infrastructure providers to rapidly ingest, test, and deploy the updated BIOS and firmware packages across vast server fleets.
Furthermore, the Mior advisory includes Trusted Computing Base (TCB) values for SNP attestation tied to each fixed firmware iteration, though guidance on how non-technical VM owners should automatically verify these remote attestation metrics remains sparse. While neither AMD nor the research teams have observed these exploits being actively leveraged in the wild prior to disclosure, the publication of functional proof-of-concept code on platforms like GitHub ensures that malicious actors will attempt to operationalize these techniques.
Security analysts emphasize that while confidential computing remains vastly more secure than traditional cloud execution models—requiring a high degree of pre-existing host access, specific hardware configurations, and sophisticated execution timing—the vulnerabilities serve as a stark reminder that hardware isolation is an evolving arms race. As chipmakers and researchers continue to probe the boundaries of silicon security, the industry must move toward more resilient, immutable boot verification mechanisms that can withstand sophisticated host-level tampering.
