AMD SEV-SNP Vulnerabilities Mior and Skyfall Expose Confidential Virtual Machine Data
Security researchers have disclosed two attacks, named Mior and Skyfall, that can undermine protections provided by AMD's Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP) technology.
Both attacks can allow a malicious host or hypervisor to access sensitive information inside confidential virtual machines (VMs). Mior goes further by allowing attackers to modify VM memory and manipulate signed attestation reports that are intended to verify the software running inside a VM.
The researchers demonstrated both attacks in laboratory tests using AMD EPYC server processors.
AMD has released SEV firmware addressing Mior and microcode updates for Skyfall, both dated August 12. However, additional platform firmware updates are planned for server manufacturers, with Skyfall fixes targeted for November and Mior fixes for December. Updates for embedded processors are scheduled for a later period.
What Are AMD SEV-SNP and Confidential VMs?
AMD SEV-SNP is a confidential computing technology available on AMD EPYC server processors. It uses hardware-enforced memory encryption and access controls to protect virtual machines, including from the hypervisor running on the host.
One of its key security mechanisms is the Reverse Map Table (RMP). The RMP tracks ownership of physical memory pages and defines how those pages can be accessed.
During VM startup, AMD's Platform Security Processor (PSP), a dedicated security co-processor, initializes the RMP.
SEV-SNP also measures a VM's software image during startup. The PSP can then sign attestation reports containing this measurement, allowing remote parties to verify the VM's software state.
The Mior and Skyfall attacks target different parts of these protections.
Mior: Manipulating Memory Protections and Attestation
The Mior attack was developed by researchers at ETH Zurich. It targets the SEV-SNP startup process and the initialization of the Reverse Map Table.
During startup, the PSP writes information into the RMP. Researchers discovered that they could redirect these writes to memory belonging to a graphics card under their control instead of the system's main memory.
The researchers believe this approach works because the PSP reads back the values it writes to verify them, and the graphics card can return the expected values.
As a result, the startup process completes without reporting an error, even though parts of the actual RMP remain uninitialized. This includes the entry responsible for protecting the RMP itself.
With those protections missing, the hypervisor can modify RMP permissions.
Researchers then demonstrated two significant capabilities:
- Unauthorized VM memory access: They enabled debugging on a confidential VM that had debugging disabled and used the PSP's debug commands to read and write its memory.
- Attestation manipulation: They copied the measurement of a harmless VM into a malicious VM, causing the malicious VM's attestation reports to describe the harmless software image.
The researchers reported that the memory debugging technique succeeded in all 1,000 attempts across two test runs.
The attack requires control of the hypervisor and BIOS (also known as UEFI), along with a PCIe device such as a graphics card. The researchers modified the BIOS during testing to leave the processor's memory-routing settings unlocked.
They tested Mior on an AMD EPYC 9135 processor based on the Zen 5 architecture. They believe Zen 3 and Zen 4 processors may also be affected, although they did not test those generations.
Importantly, both the debugging and attestation demonstrations worked even when SEV-SNP's optional ciphertext-hiding feature was enabled. This feature is designed to prevent the hypervisor from reading encrypted VM memory.
The researchers also clarified that Mior is separate from their earlier Fabricked and RMPocalypse attacks and is not related to the fix released for Fabricked. Their testing showed that Mior also worked with older firmware versions released before that fix.
Skyfall: Extracting VM Registers and Encryption Keys
The second attack, Skyfall, was developed by researchers from ETH Zurich and Google. It builds on a class of processor vulnerabilities known as Transient Scheduler Attacks (TSA), which can expose information through instruction timing.
The TSA vulnerabilities were first disclosed on July 8, 2025.
Skyfall exploits what happens when a malicious hypervisor deliberately causes a virtual machine to fail during startup.
According to the researchers, the processor may already have cached parts of the VM's saved state before the startup failure occurs. That information is not properly cleared, allowing the hypervisor to recover it through TSA techniques.
Using this approach, the researchers recovered saved register values and a disk-encryption key from a test VM.
To recover the key, they modified the VM's kernel to pause while the key was present in processor registers. For a real-world attack, they said a hypervisor could instead use a technique called SEV-Step to step through VM execution until the key reaches the registers.
Skyfall can also expose VM memory, but its capabilities are limited. It can read only three fixed cache lines within a targeted memory page:
0x0c00x3800x3c0
The remaining contents of the page stay inaccessible through this technique.
Unlike Mior, Skyfall does not require BIOS or hardware modifications. However, it still requires control of the host or hypervisor.
Researchers demonstrated Skyfall on an EPYC 7313 processor based on Zen 3 and EPYC 9124 and 9334 processors based on Zen 4. They did not demonstrate the VM data leak on Zen 5 processors.
Beyond confidential VMs, the researchers also recovered decrypted microcode updates on all three tested processors and extracted register values stored in System Management Mode (SMM) memory. SMM memory is normally inaccessible even to the operating system kernel. These additional attacks require privileged software access to the machine.
Researchers Highlight Practical Limitations of Skyfall
The Skyfall research received attention from the program committee of the IEEE Symposium on Security and Privacy, which accepted the paper.
However, the committee noted that the research does not fully address the practical requirements of carrying out a realistic attack against virtual machines.
These requirements include:
- A processor core that is not occupied by other activity.
- Repeated VM startup failures.
- High-speed performance-counter reads.
- A target VM that does not crash or time out during the attack.
These constraints may affect how easily Skyfall can be reproduced in real-world environments.
Affected AMD EPYC Processors and Security Fixes
AMD tracks the two vulnerabilities under separate CVE identifiers:
AttackCVECVSS scoreAffected technologyMiorCVE-2026-04625.9SEV-SNPSkyfallCVE-2026-406714.9VM register data exposure
AMD lists five EPYC server processor series as affected by both vulnerabilities.
EPYC seriesMior SEV firmwareMior platform firmware targetSkyfall platform firmware target70031.3A.03MilanPI-SP3_1.0.0.L (December)MilanPI-SP3_1.0.0.L (November)80041.3A.4GenoaPI_1.0.0.K (December)Genoa_100J Patch 3 (November)80051.3A.0ATurinPI_1.0.0.C (December)TurinPI_1.0.0.C (November)90041.3A.4GenoaPI_1.0.0.K (December)Genoa_100J Patch 3 (November)90051.3A.0ATurinPI_1.0.0.C (December)TurinPI_1.0.0.C (November)
AMD lists the SEV firmware and microcode updates as dated August 12. The table reflects the platform firmware targets described in the advisories.
The two advisories give the Turin platform firmware package different target months for Mior and Skyfall.
Additional updates include:
- The Instinct MI300A accelerator has a Skyfall patch dated September 21.
- Fixes for embedded EPYC processors are expected between January and April 2027.
- The Mior advisory lists only SEV-SNP as affected, not the earlier SEV and SEV-ES technologies.
The advisories do not clarify whether the released firmware and microcode updates provide protection independently or must be installed as part of a complete BIOS update. They also do not list a workaround.
Additional Skyfall Vulnerability in EDK II Firmware
Skyfall also affects System Management Mode memory through a separate vulnerability tracked as CVE-2026-18448.
The EDK II project assigned this issue a CVSS score of 5.6. AMD's advisory attributes the vulnerability to missing TSA mitigations in EDK II firmware code.
The affected products include EPYC and Ryzen processors, including embedded models.
AMD recommends applying its previously released TSA mitigations and installing the relevant EDK II patch when available.
For the five EPYC server lines listed in the main advisories, the EDK II patch is targeted for November. Platform firmware containing the fix is already available for some other processors, including EPYC 4004 and 4005 models.
The EDK II project's advisory did not list a patched version at the time of disclosure.
What Server Administrators and Cloud Customers Should Do
Organizations operating AMD EPYC infrastructure should review the affected processor models and coordinate firmware updates with their server manufacturers.
Recommended actions include:
- Check processor exposure: Identify whether servers use affected EPYC 7003, 8004, 8005, 9004, or 9005 processors.
- Update host firmware: Obtain the relevant BIOS or UEFI updates from the server manufacturer as they become available.
- Apply SEV firmware and microcode updates: Review AMD's advisories and confirm which components are required for complete mitigation.
- Check vendor-specific updates: Server manufacturers may require additional updates, including Baseboard Management Controller (BMC) firmware.
- Review Supermicro guidance: Supermicro has published a BIOS fix list covering affected H12, H13, and H14 motherboards. Its guidance also identifies BMC firmware requirements, while some products remain under testing.
- Verify confidential VM protections: Review the trusted computing base (TCB) values associated with fixed firmware versions in the Mior advisory. The advisory does not specify exactly how VM owners should perform this verification.
- Contact cloud providers: Customers renting confidential VMs generally cannot update the underlying host firmware themselves. They must rely on their cloud providers to deploy the necessary platform updates.
Both research teams have published proof-of-concept code. The Mior proof of concept requires a BIOS configuration that leaves memory-routing settings unlocked.
Neither AMD advisory reports whether the vulnerabilities have been exploited in real-world attacks.
Conclusion
Mior and Skyfall demonstrate different ways in which weaknesses in processor startup behavior, memory protection, and transient execution can undermine confidential computing.
Mior can compromise SEV-SNP memory protections and manipulate VM attestation, while Skyfall can recover selected VM register data and sensitive information under specific execution conditions.
For organizations relying on confidential virtual machines, these findings reinforce the importance of treating host firmware, processor microcode, and hardware security components as part of the overall security boundary.
Keeping hypervisors secure remains important, but confidential computing also depends on correctly configured and fully patched platform firmware.
