Research

Mior and Skyfall Let a Rogue Cloud Host Read AMD SEV-SNP Confidential VMs. Check the TCB in Your Attestation Reports

Patrick Duggan · · 8 min read

Mior and Skyfall Let a Rogue Cloud Host Read AMD SEV-SNP Confidential VMs. Check the TCB in Your Attestation Reports

If you rent AMD SEV-SNP confidential VMs because you do not want your cloud provider able to read them, do three things this week. Read the reported TCB in your VMs' attestation reports and compare its SNP field against the fixed values AMD published on Tuesday, November 10: 0x1F on EPYC 7003, 0x1E on EPYC 8004 and 9004, 0x8 on EPYC 8005 and 9005. Make your verifier reject reports below those values once your provider has rolled the fix. And ask your provider in writing which SEV firmware, microcode and platform firmware your hosts run. If you run ordinary VMs, this is not your emergency: an ordinary VM already trusts its host.

Mior and Skyfall at a glance: left column Mior (CVE-2026-0462, AMD-SB-3059, CVSS 4.0 5.9), where a malicious hypervisor reroutes the AMD security processor's Reverse Map Table writes to a PCIe device and gains read/write of confidential VM memory and forged attestation; right column Skyfall (CVE-2026-40671, AMD-SB-3061, CVSS 4.0 4.9), where a deliberately failed VMRUN leaves decrypted VM state in the L1 cache for a Transient Scheduler Attack side channel; a table of the fixed SEV firmware versions and minimum TCB SNP values per EPYC series; and a band saying who should care, who should not panic, and what to do.

The threat model, in one paragraph

SEV-SNP exists for one adversary: the party that runs the machine. AMD's confidential computing promise is that the hypervisor, the BIOS and the cloud operator behind them cannot read or tamper with a confidential VM, and that a remote party can prove what is running through an attestation report signed by the chip. Both new attacks are attacks by that adversary. The Mior paper states its threat model plainly: "The hypervisor and the BIOS are untrusted and assumed to be under attacker control." Skyfall assumes "a malicious kernel or hypervisor with standard privileged access to performance monitoring counters, physical address mappings, and VM-control interfaces." So the people who could use these are a cloud operator, an insider at one, a government that can compel one, or an attacker who has already taken over the host. That is a narrow list, and it is exactly the list confidential computing is sold to protect you from.

What is confirmed

Mior (CVE-2026-0462, AMD-SB-3059). From ETH Zurich: Chris Wech, Philipp Giersfeld, Benedict Schlüter and Shweta Shinde, to be presented at ACM CCS 2026 (November 15 to 19, The Hague). AMD's description: "Insufficient Granularity of Access Control in AMD Secure Encrypted Virtualization (SEV) firmware could allow a malicious hypervisor to potentially redirect access to MMIO memory resulting in loss of guest memory integrity." CVSS 4.0 base score 5.9, CWE-1220. AMD's table marks SEV and SEV-ES as not affected and SEV-SNP as affected.

How it works, per the paper: the AMD security processor (the PSP) checks the chip's memory routing before it sets up the Reverse Map Table, the structure that decides which memory belongs to which confidential VM. The researchers found it builds its memory map from a broadcast read that ORs every routing configuration together, so it misses routing that differs between parts of the chip. A malicious hypervisor sets up that divergent routing before the lock, and the PSP's writes to part of the table, including the entry that protects the table itself, go to a PCIe device the attacker controls instead of to memory. The paper used an NVIDIA GPU, and the device hands back the right values when the PSP reads them to check. Startup finishes without an error and the table is effectively off.

Two case studies follow. In the first, the hypervisor turns on debugging for a VM whose owner disabled it and then reads and writes the VM's memory through the PSP's own debug commands. The paper reports the attack "succeeded in all 1000 attempts for both experiment runs", with and without the optional ciphertext hiding feature, averaging about two tries and under 2 milliseconds. In the second, the hypervisor copies a benign VM's measurement into a malicious VM, so the attestation report describes an image that is not running. That second one matters most for anyone who relies on attestation: the signed report itself can lie on an unpatched host.

Hardware tested: one EPYC 9135, a Zen 5 part. AMD's bulletin lists EPYC 7003, 8004, 8005, 9004 and 9005 as affected. The researchers reported it to AMD on February 12, 2026, and their code is public at github.com/xca-attacks/mior.

Skyfall (CVE-2026-40671, AMD-SB-3061). From Benedict Schlüter, Alessandro Vezzù and Shweta Shinde at ETH Zurich and Daniel Moghimi at Google, accepted at IEEE S&P 2027. AMD's description: "Incomplete cleanup during VMRUN error handling could allow access to a Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP) guest register state, potentially resulting in information disclosure and impacts to confidentiality." CVSS 4.0 base score 4.9, CWE-459.

How it works, per the paper: it builds on the Transient Scheduler Attacks AMD disclosed in July 2025. The hypervisor writes an invalid value into the VM control block and starts the VM. VMRUN aborts, but only after the CPU has loaded the VM's decrypted saved state into the L1 data cache, and AMD's existing TSA mitigation is not applied on that path. A side channel then reads it back. Results on the tested chips: a register marker recovered "with 100% accuracy", and an AES-XTS disk encryption key recovered from a minimal Linux guest. That key demo used a modified guest kernel that stopped right when the key sat in registers; the paper says a real attacker would use SEV-Step single-stepping to reach that point. The same trick reads guest memory too, but only three cache lines per page, at offsets 0x0c0, 0x380 and 0x3c0.

Hardware tested: EPYC 7313 (Zen 3) and EPYC 9124 and 9334 (Zen 4). The paper does not show the leak on Zen 5, but AMD's bulletin still lists the Zen 5 EPYC 8005 and 9005 lines with fixes. The researchers reported to AMD on April 21, 2026. Their code is public at github.com/skyfall-attack.

A third bulletin, for a wider audience (CVE-2026-18448, AMD-SB-7072). The Skyfall team also read System Management Mode memory and decrypted microcode updates. AMD traces the SMM part to "the absence of TSA (Transient Scheduler Attacks) mitigations in EDK2", the open-source firmware base, scored 5.6. It needs a kernel-level attacker on the machine, and it covers Ryzen desktops and laptops as well as EPYC. For those, it is an ordinary BIOS update on your normal cadence.

All three AMD bulletins are dated 2026-11-10, initial version. CISA's Known Exploited Vulnerabilities catalog does not list any of the three CVEs as of catalog version 2026.11.13, which we checked against the CISA JSON.

What the fix is, exactly

For Mior, AMD released SEV firmware on 2026-08-12 and plans platform firmware for December 2026:

  • EPYC 7003: SEV firmware 1.3A.03, TCB[SNP]=0x1F, platform firmware MilanPI-SP3_1.0.0.L, "Target release planned for Dec'26"
  • EPYC 8004 and 9004: SEV firmware 1.3A.4, TCB[SNP]=0x1E, platform firmware GenoaPI_1.0.0.K, December 2026
  • EPYC 8005 and 9005: SEV firmware 1.3A.0A, TCB[SNP]=0x8, platform firmware TurinPI_1.0.0.C, December 2026
  • Embedded EPYC 7003, 8004, 9004 and 9005: "Version TBD", February 2027

AMD also lists a "Mitigation Bit" per line (8 for 7003, 6 for 8004 and 9004, 12 for 8005 and 9005). The bulletin does not explain where a VM owner reads it.

For Skyfall, AMD released microcode on 2026-08-12 and plans platform firmware for November 2026:

  • EPYC 7003: Milan-B1 0x0A0011E1, Milan-B2 0x0A00124E; platform firmware MilanPI-SP3_1.0.0.L
  • EPYC 8004: Siena 0x0AA0021F; platform firmware Genoa_100J Patch 3
  • EPYC 9004: Genoa-B1 0x0A10115B, Genoa-B2 0x0A10125B, Bergamo 0x0AA0021F; platform firmware Genoa_100J Patch 3
  • EPYC 8005 and 9005: Turin Classic 0x0B002176, Turin Dense 0x0B101067; platform firmware TurinPI_1.0.0.C
  • Instinct MI300A: 0x0A900110, released 2026-09-21
  • Embedded EPYC: January to April 2027

Two things the bulletins leave open. First, neither says whether the August firmware or microcode is enough on its own or only together with the platform firmware still to come; both tell customers to get the BIOS from their server maker. Second, AMD gives attestation TCB values for Mior but not for Skyfall. The SNP attestation report does carry a microcode component in its TCB, but AMD's Skyfall bulletin lists microcode revision numbers, not the TCB value a verifier should require. Note too that the same platform firmware name, TurinPI_1.0.0.C, appears as a November target in one bulletin and a December target in the other.

Who should care, and who should not panic

Care: anyone whose security argument says "the cloud provider cannot see this". That means regulated workloads that cite confidential computing to an auditor or regulator, key custody and signing services in confidential VMs, confidential AI where model weights or prompts are meant to be hidden from the host, and any service that releases secrets to a VM only after checking its attestation report. Mior's forged-attestation case is aimed squarely at that last group.

Do not panic: ordinary cloud VMs, which have always trusted the host, and which these attacks give the host nothing new against. The Hacker News reports the Mior researchers saying as much; we did not find that line in the paper itself. Anyone not using SEV-SNP. And anyone worried about a stranger on the internet: neither attack is reachable from the network or from inside a guest. Both need control of the host, and Mior additionally needs the platform firmware and a PCIe device. The Skyfall paper's own program committee said it overlooks what a realistic attack against a VM would require, including a quiet core and failing VM starts at high frequency. Treat Skyfall as a demonstrated leak under lab conditions, not a turnkey tool.

What you can actually do

  1. Pull a fresh attestation report from each confidential VM and read the SNP field of the reported TCB. Compare it with the values above for your EPYC generation. Your provider's documentation or the guest's CPU information tells you which generation you are on.
  1. Once your provider confirms the rollout, make your attestation verifier or key release policy require at least those TCB values, and reject anything below. A verifier that checks only the signature and the launch measurement does not protect you here, because on an unpatched host Mior can forge the measurement.
  1. Ask your provider, in writing, which SEV firmware version, microcode revision and platform firmware your hosts run, when they will be on the versions in AMD-SB-3059 and AMD-SB-3061, and whether they will publish a bulletin. You cannot install any of these fixes yourself; renting a confidential VM means relying on the provider for this.
  1. Run your own EPYC hosts with SEV-SNP? Get the BIOS from your server maker. The Hacker News reports that Supermicro published a fix list for dozens of H12, H13 and H14 boards and says those boards also need a BMC firmware update; Supermicro's page returned HTTP 403 to us, so we could not read it ourselves.
  1. Ryzen and EPYC 4004/4005 owners: install your next BIOS update when it carries the AMD-SB-7072 fix. AMD lists ComboAM5PI 1.2.0.3m, released 2026-09-24, for EPYC 4004 and 4005. This is routine patching, not an incident.

What is not known

Exploitation in the wild: no primary we read says it has happened, and none says it has not. Both teams' code is now public.

Cloud provider status: as of November 13 we found no statement naming these CVEs from Google Cloud, AWS or Microsoft Azure. Google Cloud's Confidential VM security bulletins page lists nothing newer than GCP-2026-053 from August. Google's general bulletin GCP-2026-081 of November 10 covers different TSA flaws on Turin, not these. AWS's bulletin list showed nothing on them, and a search turned up no Azure advisory. No statement is not the same as no fix: providers may already have rolled the August firmware and microcode. Ask.

Zen 3 and Zen 4 for Mior, and Zen 5 for Skyfall: AMD lists all of them as affected, but the papers tested only the hardware named above.

How we know, and what we did not do

We read both papers as PDFs (converted with pdftotext) and AMD's three bulletins directly; quotes and version numbers above come from them, not from the press. The Hacker News article was our lead and the source for the Supermicro detail. GitHub's API shows the Mior repository and the Skyfall organization's repositories as public. November 10, 2026 was checked as a Tuesday against the calendar.

Our edge instruments cannot see this class of attack: it happens inside the host's CPU and firmware, not in network traffic, so there is no edge check to report. Indicators: none published in the sources we read, and we added nothing to the feed.

Sources

  • The Hacker News, "New Mior and Skyfall Attacks Let Rogue Cloud Hosts Steal Secrets From AMD SEV-SNP VMs", November 13, 2026: https://thehackernews.com/2026/11/new-mior-and-skyfall-attacks-let-rogue.html
  • Wech, Giersfeld, Schlüter, Shinde, "Mior: Breaking AMD SEV-SNP with Device-as-Memory", ACM CCS 2026: https://xca-attacks.github.io/mior/mior_ccs26.pdf
  • Mior code: https://github.com/xca-attacks/mior
  • Schlüter, Vezzù, Moghimi, Shinde, "Skyfall: Microarchitectural Data Sampling on AMD", IEEE S&P 2027: https://skyfall-attack.github.io/assets/skyfall.pdf
  • Skyfall code: https://github.com/skyfall-attack
  • AMD-SB-3059, AMD Secure Encrypted Virtualization (SEV) Vulnerability (CVE-2026-0462): https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3059.html
  • AMD-SB-3061, AMD SEV Incomplete Cleanup Vulnerability (CVE-2026-40671): https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3061.html
  • AMD-SB-7072, EDK II Mitigations for Transient Scheduler Attacks (CVE-2026-18448): https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7072.html
  • Google Cloud Confidential VM security bulletins: https://docs.cloud.google.com/confidential-computing/confidential-vm/docs/security-bulletins
  • Google Cloud security bulletins: https://docs.cloud.google.com/support/bulletins
  • AWS security bulletins: https://aws.amazon.com/security/security-bulletins/
  • CISA Known Exploited Vulnerabilities catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Every indicator in this post is in the feed. Free.

1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.

Get your free key → analytics.dugganusa.com/stix/register