Mior and Skyfall: Malicious Hosts Break AMD SEV-SNP Attestation

Key Takeaways

Two research teams centered at ETH Zurich, one of them including Google researchers, have published two technically distinct attacks against AMD Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP), the hardware technology that underpins AMD-based confidential virtual machines (CVMs) across the major clouds. AMD released advisories for both on November 10, 2026, when the research embargo lifted, and press coverage followed on November 13 [1][2][3][4]. Both attacks assume the adversary SEV-SNP is specifically designed to defeat: a cloud operator, or an intruder holding equivalent privileges, who controls the hypervisor. Neither attack requires hardware modification of the CPU. Skyfall needs only hypervisor control, while Mior additionally requires control of BIOS/UEFI configuration and an attacker-controlled PCIe device. Those conditions are within reach of a cloud operator or a fully compromised host, although that is an inference rather than a demonstrated scenario.

Mior (CVE-2026-0462, AMD-SB-3059) gives an attacker who controls the hypervisor, BIOS/UEFI configuration, and an attached PCIe device arbitrary read and write access to CVM memory, and lets that attacker forge attestation measurements. A malicious guest image can therefore present the launch measurement of a benign one. The researchers report that the attack succeeded in all 1,000 trials on a Zen 5 EPYC 9135 [4]. Skyfall (CVE-2026-40671, AMD-SB-3061), by contrast, is a transient-execution attack that builds on AMD’s 2025 Transient Scheduler Attacks (TSA). It leaks CVM register state through a flaw in VMRUN error handling, and the researchers used it to recover a disk-encryption key from a test guest [2][5]. Both research teams have released proof-of-concept code, although the Mior code requires a BIOS modified to leave memory-routing settings unlocked [3][4][5].

The fixes are host-side. They arrive as SEV firmware, microcode, and OEM BIOS updates, with AMD’s platform-initialization packages targeted for November and December 2026 [1][2]. Tenants cannot patch from inside the guest. Their main control is to have attestation verifiers reject reports from platforms that have not reached the fixed Trusted Computing Base (TCB) level.

Confidential AI deployments inherit the exposure. Confidential GPU deployments that protect model weights and inference data are anchored in a CPU confidential VM, and NVIDIA lists SEV-SNP on Milan and Genoa as a supported host configuration [6]. No GPU-specific attack was demonstrated, but GPU confidentiality depends on the integrity of the CPU CVM and its attestation, including the CVM memory that holds GPU session keys. AMD’s Skyfall bulletin also lists a fix for the Instinct MI300A accelerator, dated September 21, 2026 [2]. On an unpatched host, both the AI workload and the attestation evidence used to release keys to it should be treated as untrustworthy.

Background

Confidential computing aims to protect data while it is being processed, so that the cloud provider’s privileged software cannot read or alter a tenant’s workload. AMD’s implementation, SEV-SNP, encrypts each guest’s memory with a per-VM key. Integrity is enforced through a Reverse Map Table (RMP), which records which guest owns each physical page. The Platform Security Processor (PSP), an Arm core on the EPYC die, initializes the RMP, manages guest launch, and signs the attestation reports a tenant uses to confirm what software is running and on what firmware [4]. The SEV-SNP threat model explicitly treats the hypervisor and the BIOS/UEFI as untrusted. That design choice is what makes confidential VMs attractive for regulated data, proprietary model weights, and multi-party AI workloads.

That threat model has been under steady academic pressure. Prior work has shown interrupt-injection attacks (WeSee), single-stepping frameworks (SEV-Step), and a series of what the Mior authors call Interconnect Corruption Attacks, in which manipulation of AMD’s Infinity Fabric undermines PSP guarantees [4][7][8][14]. In July 2025, AMD disclosed Transient Scheduler Attacks, a family of timing side channels in the instruction scheduler with CVSS scores of up to 5.6 [9]. Mior and Skyfall extend both lines of research, the interconnect line and the transient-execution line respectively. Mior is a new flaw rather than a bypass of earlier interconnect fixes, while Skyfall exploits incomplete coverage in AMD’s existing TSA mitigations. The Mior authors describe their attack as a vulnerability unrelated to the earlier Fabricked attack and its mitigation [4][14]; their main experiments ran on current SEV firmware, which mitigates Fabricked, and they also tested older firmware that predates the Fabricked fix [4].

The disclosure timeline points to a long coordinated process. The Mior team reported to AMD in February 2026 [4]. The Skyfall team reported its SEV-SNP findings on April 21, 2026, and sent follow-up findings on System Management Mode (SMM) and HyperTransport on May 28 [5]. AMD’s SEV firmware and microcode fixes carry release dates of August 12, 2026, and both bulletins were first published on November 10 [1][2]. Mior will be presented at ACM CCS 2026 in The Hague, which runs November 15 to 19 [4], and Skyfall has been accepted to the IEEE Symposium on Security and Privacy 2027 [3][5].

Security Analysis

The two attacks reach the same outcome, a host that can see or alter what a confidential VM is supposed to keep private, by very different routes. Mior corrupts the PSP’s understanding of physical memory during platform initialization, while Skyfall samples guest data that leaks through speculative execution when a VM launch fails. The subsections below examine each mechanism, compare the two side by side, and then consider why the tenant has so little direct leverage over either.

Mior: Corrupting the PSP’s View of Memory

Mior exploits the way the PSP decides which physical addresses are safe DRAM and which are memory-mapped I/O (MMIO). During SEV-SNP initialization, the PSP reads the Data Fabric routing configuration and builds a memory map, which it then uses to catch any misrouting of its own accesses. The researchers found that the PSP builds this map from an OR-sum of the routing registers across all Data Fabric units. When those units are configured asymmetrically, so that different ingress points see different memory layouts, the map no longer reflects the real routing [4]. A hypervisor that also controls BIOS/UEFI configuration can exploit the gap. It routes PSP writes intended for the RMP to the MMIO region of a PCIe device it controls (the researchers used an NVIDIA RTX 3080), a technique they call the “Device-as-Memory” primitive. Initialization then completes without error, but critical RMP entries, including the one protecting the RMP itself, are left uninitialized [4]. According to press reports, the test setup used a modified BIOS that left memory-routing settings unlocked [3].

With the RMP in that state, the researchers demonstrated two end-to-end attacks. In the first, the hypervisor enabled debugging on a CVM whose policy prohibited it. It then used PSP debug commands to read and write guest memory, and restored the original policy afterwards so that the guest saw nothing unusual. The average completion time was about 1.7 milliseconds, and the attack succeeded in all 1,000 attempts, with ciphertext hiding both enabled and disabled [4]. The second attack targets attestation directly. Because SEV-SNP computes the launch measurement once and stores it in the guest context page, the attacker can boot a benign image, snapshot that page’s ciphertext, and then launch a malicious image at the same physical location. It then overwrites the new measurement with the benign one. Every attestation report the malicious guest subsequently requests describes the benign image [4]. The researchers note that ciphertext hiding, an optional SEV-SNP hardening feature, does not affect this attack, because the guest context page is not encrypted in the same way as ordinary guest memory [4].

The forgery result is the most consequential part of the disclosure for AI deployments. Remote attestation is usually the gate that releases model-decryption keys, dataset keys, or federated-learning credentials to a workload. If the measurement can be transplanted, an operator can run instrumented or exfiltrating code that passes the same policy check as the approved image. AMD rates CVE-2026-0462 at CVSS 4.0 5.9, with high integrity impact on subsequent systems, and lists only SEV-SNP as affected, not the older SEV or SEV-ES modes [1]. The researchers tested only Zen 5 hardware and believe Zen 3 and Zen 4 parts may also be affected. AMD’s bulletin lists the EPYC 7003, 8004, 8005, 9004, and 9005 series [1][4]. The authors also argue that similar memory-routing issues may affect other TEE architectures, citing an Intel-reported TDX configuration-register flaw [4][15]. They did not study Intel TDX or Arm CCA themselves, however, so this remains an inference rather than a demonstrated result.

Skyfall: Microarchitectural Data Sampling on AMD

Skyfall takes a different route, through speculative execution rather than platform configuration. The researchers adapted Transient Scheduler Attacks into a technique resembling Intel’s Microarchitectural Data Sampling (MDS). They used AMD’s Instruction Based Sampling performance feature to reverse-engineer the VERW-based TSA mitigations, and found that those mitigations cover virtual-address-based leaks while leaving physical-address paths exposed. The exposed paths are the ones used by privileged instructions such as VMRUN, VMLOAD, and VMSAVE [5]. When a hypervisor deliberately makes a CVM launch fail, the processor has already pulled part of the guest’s encrypted save area into the cache and does not clean it up, so the hypervisor can then sample that data through the TSA channel [2][5]. AMD’s bulletin describes the issue as incomplete cleanup during VMRUN error handling, rates it CVSS 4.0 4.9, and limits its stated impact to confidentiality [2].

The demonstrated impact is narrower than Mior’s but includes recovery of a disk-encryption key. The researchers recovered a test CVM’s saved register values along with that key. To capture the key, they modified the guest kernel to pause while the key was held in registers, and press coverage notes that a real attacker would likely need SEV-Step to single-step the guest to the same point [3][5]. Only three fixed cache lines in a targeted page, at offsets 0x0c0, 0x380, and 0x3c0, are readable [3][5]. Testing covered Zen 3 and Zen 4 EPYC parts, and the leak was not shown on Zen 5 [3][5]. The researchers also used Skyfall to extract decrypted AMD microcode patches and to leak SMM memory [5]; the SMM issue is tracked separately as CVE-2026-18448 in EDK II firmware [3]. The IEEE S&P program committee reportedly noted that a realistic attack would need an otherwise idle core, rapid launch failures with performance-counter reads, and a victim that does not crash or time out [3]. Those conditions are demanding, but most of them fall within what a cloud operator controls. AMD’s bulletin also lists a Skyfall fix for the AMD Instinct MI300A accelerator, dated September 21, 2026, which places at least one AMD AI accelerator platform within the affected scope [2].

Comparative Summary

Because the two attacks differ in mechanism, affected generations, and remediation path, defenders should track them separately. The following table summarizes the attributes most relevant to prioritization and patch verification.

The table makes clear that Mior is the more serious concern for any workload that relies on attestation to gate secrets, while Skyfall is the more serious concern for older Zen 3 and Zen 4 fleets where long-lived secrets sit in guest registers.

Why the Cloud Tenant Is the Weak Party

Both remediations sit entirely below the guest. AMD distributes PI firmware to OEMs and instructs customers to obtain BIOS updates from their server vendor [1][2]. A tenant renting a confidential VM therefore depends on the provider to deploy SEV firmware, microcode, BIOS, and in some cases BMC updates. Supermicro’s advisory for these issues, for example, states that a BMC firmware update is also required [3]. Embedded EPYC fixes are not scheduled until January to April 2027 [1][2]. The advisories also do not say whether the microcode or SEV firmware updates are effective on their own or only in combination with the PI/BIOS update, which leaves open whether a platform reporting the fixed TCB is fully mitigated before the November and December BIOS releases [3]. At the time of writing, neither AMD nor any cloud provider has said publicly whether these flaws have been exploited in the wild, and none of the coverage reviewed for this note quotes a hyperscaler on its deployment status [3].

The tenant still holds one control: the attestation verifier. AMD-SB-3059 publishes, for each EPYC family, the SEV firmware version and the TCB[SNP] value that mark a mitigated platform. These are 0x1F for the 7003 series, 0x1E for the 8004 and 9004 series, and 0x8 for the 8005 and 9005 series [1]. SNP attestation reports carry the platform’s reported TCB, and the signing key (VCEK) is derived from that TCB. A verifier that rejects reports below the published minimum therefore refuses keys to unpatched platforms, which is exactly where Mior forgery is possible. Because the thresholds differ by family, the verifier must determine the processor family from the attestation report or VCEK certificate chain and apply the matching minimum; a single numeric threshold across families would either reject every patched Zen 5 platform or accept unpatched older ones. This control also depends on the verifier enforcing the TCB check rather than validating only the measurement and signature, a check that custom verifiers do not always implement and that AMD’s advisory does not explain how to perform [3]. AMD-SB-3061 does not list equivalent TCB values for Skyfall. Tenants should therefore ask their providers how a Skyfall-patched microcode level will appear in attestation evidence [2].

Recommendations

The recommendations below are ordered by time horizon. Because exploitation of either flaw requires a malicious or compromised host operator, organizations should scale their response to the sensitivity of the assets involved and to each provider’s confirmed patch status, recognizing that some providers may have deployed the August 2026 firmware before public disclosure.

Immediate Actions

Organizations running sensitive or AI workloads on AMD SEV-SNP confidential VMs should first inventory every such deployment. The inventory should cover AI inference and training enclaves, key-management services, confidential containers, and confidential GPU nodes, and should record each host’s EPYC generation, along with any MI300A-based systems. For each provider, request written confirmation of the deployment status and timeline for AMD-SB-3059 and AMD-SB-3061 fixes, including BIOS and BMC components where relevant, and ask whether the reported TCB reflects full mitigation or only a partial one (firmware or microcode without the BIOS update). Update attestation verification policy to require the AMD-SB-3059 minimum TCB[SNP] values for each relevant processor family, and configure verifiers to fail closed. Until a host is confirmed patched, treat secrets released to it on the basis of attestation as potentially exposed. Model-decryption keys, dataset keys, and signing credentials are the priority for rotation once the platform is remediated, with rotation prioritized according to asset sensitivity and the provider’s confirmed patch status.

Short-Term Mitigations

Over the next one to three months, organizations should review their attestation pipelines end to end. The goal is to confirm that TCB components, including microcode, are enforced and not merely logged, and that the verifier can be updated quickly when AMD publishes new minimums. Where workloads are especially sensitive, consider moving them temporarily to platforms confirmed as patched, or reduce the volume of long-lived secrets resident in guest memory, which limits what a Skyfall-style register leak can capture. Self-hosted operators should apply AMD PI and OEM BIOS updates as they become available. They should also lock BIOS/UEFI configuration and restrict which PCIe devices can be attached to SEV-SNP hosts, since Mior relies on attacker-controlled devices and routing configuration [4]. On infrastructure they operate themselves, where the realistic threat is a malicious insider, security teams should also monitor for anomalous patterns of failed CVM launches, which Skyfall uses as its trigger [2].

Strategic Considerations

These disclosures reinforce a point that applies to all hardware TEEs. Confidential computing reduces the trust a tenant must place in a cloud operator, but it does not eliminate that trust, and the residual trust shifts to the hardware vendor’s firmware supply chain and the operator’s patch cadence. For high-value AI assets, organizations should consider defense in depth that does not rest on a single TEE, combining split-key or threshold release of model keys, independent attestation verification services, and contractual commitments on firmware patch timelines and disclosure. As confidential I/O extensions such as AMD SEV-TIO bring accelerators into the trust boundary, the Mior authors warn that correctly modeling asymmetric routing becomes harder still [4]. Teams evaluating confidential GPU architectures should ask vendors how interconnect-level attacks are addressed in those designs.

CSA Resource Alignment

CSA’s most directly relevant prior work is Healthcare Confidential Computing and the Trusted Execution Environment, which explains how TEEs and attestation can protect sensitive data in use and positions remote attestation as the basis for trusting a remote enclave [10]. Mior shows the limits of that assumption. Attestation is only as trustworthy as the firmware generating it, and verifiers must therefore enforce TCB versioning as well as measurement checks. Healthcare and other regulated organizations following that paper’s guidance should add explicit TCB-minimum policies and patch-status attestation from providers to their adoption criteria.

The CSA Confidential Computing Working Group, whose 2024 charter sets its scope across TEE standards and best practices, cloud deployment challenges, and operator and insider threats, is the natural venue for turning lessons from Mior and Skyfall into cross-vendor practice [11]. Attestation verification baselines and shared-responsibility expectations for firmware patching are two topics within that scope that these disclosures make directly relevant.

At the control level, the AI Controls Matrix (AICM) v1.1 provides the framework for operationalizing these recommendations [12]. Its Threat and Vulnerability Management domain covers timely remediation of platform vulnerabilities. Its Cryptography, Encryption and Key Management domain governs conditional key release and rotation. Its Supply Chain Management, Transparency and Accountability domain supports contractual requirements on cloud providers’ firmware patch cadence. For assurance, CSA STAR for AI offers a mechanism through which providers of confidential AI services can document how they track hardware advisories and enforce attestation baselines [13].

References

[1] AMD. “AMD Secure Encrypted Virtualization (SEV) Vulnerability, AMD-SB-3059.” AMD Product Security, November 10, 2026.

[2] AMD. “AMD SEV Incomplete Cleanup Vulnerability, AMD-SB-3061.” AMD Product Security, November 10, 2026.

[3] Khandelwal, S. “New Mior and Skyfall Attacks Let Rogue Cloud Hosts Steal Secrets From AMD SEV-SNP VMs.” The Hacker News, November 13, 2026.

[4] Wech, C., Giersfeld, P., Schlüter, B., and Shinde, S. “Mior: Breaking AMD SEV-SNP with Device-as-Memory.” Proceedings of ACM CCS 2026, November 2026. Code: github.com/xca-attacks/mior.

[5] Schlüter, B., Vezzù, A., Moghimi, D., and Shinde, S. “SKYFALL: Microarchitectural Data Sampling on AMD.” IEEE Symposium on Security and Privacy (S&P), 2027. Project page: skyfall-attack.github.io.

[6] NVIDIA. “Confidential Containers: Supported Platforms.” NVIDIA Documentation, accessed November 14, 2026.

[7] Wilke, L., Wichelmann, J., Rabich, A., and Eisenbarth, T. “SEV-Step: A Single-Stepping Framework for AMD-SEV.” arXiv, July 2023.

[8] Schlüter, B., Sridhara, S., Bertschi, A., and Shinde, S. “WeSee: Using Malicious #VC Interrupts to Break AMD SEV-SNP.” arXiv, April 2024.

[9] AMD. “AMD Transient Scheduler Attacks, AMD-SB-7029.” AMD Product Security, July 2025.

[10] Cloud Security Alliance. “Healthcare Confidential Computing and the Trusted Execution Environment.” CSA Health Information Management Working Group, 2025.

[11] Cloud Security Alliance. “Confidential Computing Working Group Charter 2024.” CSA, 2024.

[12] Cloud Security Alliance. “AI Controls Matrix (AICM) v1.1.” CSA, June 2026.

[13] Cloud Security Alliance. “STAR for AI.” CSA, accessed November 14, 2026.

[14] Schlüter, B., Wech, C., and Shinde, S. “FABRICKED: Misconfiguring Infinity Fabric to Break AMD SEV-SNP.” USENIX Security Symposium, 2026.

[15] Intel. “Trusted Execution Configuration Register Access.” Intel Software Security Guidance, 2024.