Two attacks disclosed this week, Mior and Skyfall, allow a malicious host to access data inside AMD SEV-SNP virtual machines designed to keep the host out. If you're an enterprise risk manager with workloads in confidential computing, you've likely encountered questions about this in a Slack channel or a risk committee. Here are the questions you should expect, with direct answers.
Q1: Do we need to panic? Is anyone actually exploiting this?
No need to panic, but don't dismiss it as purely academic. AMD's advisories don't indicate these flaws have been exploited yet. However, the research teams have published code, which shortens the time from "lab demo" to "real-world attempt." Mior requires control of the hypervisor and the BIOS, plus a PCIe device like a graphics card. Skyfall needs a malicious host or hypervisor but no hardware tampering. The IEEE Symposium on Security and Privacy noted that Skyfall's VM attack overlooks realistic constraints, such as needing a processor core free of other activity and a VM that doesn't crash mid-attack. Treat this as a real but limited risk. The attackers capable of this are precisely those your confidential computing was meant to block.
Q2: So who is the attacker here? We don't run our own hypervisors.
That's the issue. SEV-SNP's threat model assumes the host operator is untrusted. The Mior researchers state that AMD explicitly distrusts the UEFI, so a modified BIOS is within the threat model. The attacker could be a rogue cloud administrator, a compromised provider employee, or anyone who gains hypervisor-level control of the server your VM runs on. If you rent confidential VMs, you've been assured you don't have to trust the provider's staff. These attacks show that promise has gaps. For your risk register, consider insider threats at your cloud provider and management plane compromises as scenarios worth reevaluating.
Q3: What did the attacks actually break?
Two different vulnerabilities were exploited. Mior corrupts the Reverse Map Table, which records who owns each memory page and what they can do with it. The ETH Zurich team redirected the Platform Security Processor's writes during start-up to a graphics card they controlled, leaving part of the table uninitialized. This allowed the hypervisor to rewrite protections, enabling them to activate debugging for a VM and access its memory. It succeeded in all 1,000 attempts across test runs, even with ciphertext hiding enabled. They also copied a harmless VM's measurement into a malicious VM, making its attestation reports describe the wrong image.
Skyfall builds on Transient Scheduler Attacks. When a hypervisor deliberately makes a VM fail to start, the processor leaves part of the VM's saved state cached without cleanup, allowing the hypervisor to read it. The team recovered register values and a disk-encryption key from a test VM. It can also read VM memory, but only three fixed cache lines in a targeted page.
The attestation result is critical for governance. If your assurance model is "we verify the signed report before releasing secrets," Mior shows that report can be falsified.
Q4: When do we get fixes, and who actually applies them?
AMD lists SEV firmware for Mior and microcode for Skyfall, both dated August 12. Platform firmware, which goes to server makers, is planned for November for Skyfall and December for Mior. Fixes for embedded EPYC chips are expected between January and April 2027. Customers should obtain the BIOS update from their server maker. Supermicro, for example, has published a BIOS fix list for its H12, H13, and H14 boards, noting that the boards also need a BMC firmware update.
If you rent confidential VMs, you can't install these updates yourself. The fixes reside in the host's firmware, so you're dependent on your provider. This makes patch cadence a contractual and due-diligence issue, not just a technical one. The advisories list no workaround and don't specify whether the August updates work independently or only within the full BIOS updates.
Q5: What should we ask our cloud provider right now?
Ask for specifics, in writing:
- Which EPYC generations host our confidential workloads (7003, 8004, 8005, 9004, 9005 are affected)?
- Have the August SEV firmware and microcode updates been deployed, and when will the November and December platform firmware be implemented?
- What is your process for confirming firmware versions across the fleet?
- Can we verify updated TCB values in our own attestation checks? AMD's Mior advisory lists TCB values next to each fixed firmware version but doesn't explain how VM owners should check them, so press your provider for that guidance.
- How do you restrict and log administrator access to hypervisor and BIOS configuration?
Vague answers are an answer. Record them for your next vendor risk review.
Q6: Does this change what we tell our insurer?
It may affect how you answer the Underwriting Questionnaire and how you think about coverage. Confidential computing is sometimes cited as a compensating control for sensitive workloads. If you've described it that way, ensure the description doesn't overstate what the technology guarantees, as an inaccurate statement can create Application Fraud Warranty exposure. On the coverage side, a provider-side compromise that exposes your data is a Contingent Business Interruption and data exposure question. Check whether your Stand-Alone Cyber Policy covers losses originating at a cloud provider, and what dependent-system language applies. Talk to your broker before renewal, not during a claim. Under the NIST CSF Core Functions, this belongs in Identify (asset and supplier dependencies) and Protect (compensating controls), with a documented reassessment.
Where to go for more
Start with AMD's two security advisories: CVE-2026-0462 for Mior (rated 5.9 on CVSS 4.0) and CVE-2026-40671 for Skyfall's VM leak (rated 4.9). AMD's EDK II bulletin covers the related SMM leak, CVE-2026-18448 (rated 5.6), with a patch due in November. For your own hardware, check your server maker's BIOS and BMC pages. For your cloud workloads, your provider's security bulletins and account team are the source of truth. Bring your broker into the conversation early.
