Mior and Skyfall break AMD SEV-SNP confidential VM guarantees

Two attacks disclosed this week defeat AMD SEV-SNP, the technology that is supposed to keep a cloud operator out of the confidential VMs it hosts. Mior (ETH Zurich) can read and modify VM memory and forge the signed attestation report that proves which software a VM runs. Skyfall (ETH Zurich and Google) leaks a VM's saved registers and its disk-encryption key. Both assume a malicious host — the exact adversary SEV-SNP is built to neutralize. Neither advisory reports in-the-wild exploitation.

What each attack does

Mior — tracked as CVE-2026-0462 (CVSS 5.9), AMD bulletin SB-3059. AMD describes it as a malicious hypervisor manipulating Memory-Mapped I/O routing to break SEV-SNP integrity. Per The Hacker News, it reads VM memory via the PSP's debug commands even where debugging was disabled, can write VM memory, and can fake an attestation report by copying a benign VM's measurement into a malicious one. It needs control of the hypervisor and the UEFI/BIOS, plus a PCIe device such as a GPU. AMD lists only SEV-SNP as affected — not SEV or SEV-ES. Demonstrated on an EPYC 9135 (Zen 5); Zen 3 and Zen 4 are listed as potentially affected but untested.

Skyfall — tracked as CVE-2026-40671 (CVSS 4.9), AMD bulletin SB-3061, "SEV Incomplete Cleanup." Building on Transient Scheduler Attacks, it recovers a VM's saved register values and its disk-encryption key, reading three fixed cache lines in a targeted page (offsets 0x0c0, 0x380, 0x3c0). It needs only a malicious host or hypervisor — no hardware tampering. A related SMM-register leak is tracked separately as CVE-2026-18448 (CVSS 5.6, EDK II). Demonstrated on EPYC 7313 (Zen 3) and 9124/9334 (Zen 4); the leak was not shown on Zen 5. Reporters include ETH Zurich researchers and Google's Daniel Moghimi.

Why it matters, and the caveat

SEV-SNP underpins "confidential computing" offerings at AWS, Azure, and Google Cloud, whose pitch is that the operator cannot read tenant VMs. Mior's attestation forgery is the sharper result: if a host can produce a valid-looking report for a tampered VM, the cryptographic proof a relying party checks no longer means what it claims. The caveat is the threat model — both attacks require control of the host (Mior also the firmware), i.e., a malicious or already-compromised provider. This is not remote exploitation of a tenant.

Action checklist

1. Apply microcode and platform-firmware updates from your server vendor as they land. AMD's microcode for affected EPYC lines is dated August 12; platform firmware is targeted for November (Skyfall) and December (Mior), per the bulletins.
2. Get BIOS updates from the hardware maker, not AMD directly; Supermicro, for one, has published a fix list.
3. If you rely on SEV-SNP attestation for trust decisions, re-examine assumptions in light of Mior's forgery result, especially where the host is not fully trusted.
4. Track the embedded/Instinct timelines if you run those parts — AMD lists MI300A fixed September 21 and embedded EPYC fixes due January–April 2027.

Context

Confidential-computing primitives keep falling to researchers who model exactly the adversary the primitive promises to stop — the malicious host. The practical risk is low for most tenants today, but the attestation-forgery angle erodes the specific guarantee that makes SEV-SNP worth paying for. Treat the fixes as firmware hygiene, and treat vendor claims about "operator can't see your data" as weaker than the marketing until the microcode and BIOS updates are actually deployed.