Red Team

Mior and Skyfall attacks let rogue cloud hosts break AMD SEV-SNP VMs

ETH Zurich’s Mior and Skyfall attacks let a hostile host read AMD SEV-SNP confidential VMs. What UK firms relying on confidential computing should ask.

Server rack graphic with the headline Rogue hosts break into confidential VMs

Two academic attacks, Mior and Skyfall, show that a hostile cloud host can reach inside AMD SEV-SNP confidential virtual machines without touching the hardware. For UK organisations that bought confidential computing so they would not have to trust their provider, the fixes depend entirely on that provider patching its firmware.

What happened

AMD has published two bulletins on attacks against SEV-SNP, the feature behind confidential virtual machines on its EPYC server chips. Both came from ETH Zurich, with a Google researcher co-authoring Skyfall, and were reported by The Hacker News on 13 November 2026. Papers and proof-of-concept code are public.

Mior is tracked as CVE-2026-0462 in bulletin AMD-SB-3059, first published on 10 November, and carries a CVSS 4.0 score of 5.9. AMD describes it as a malicious hypervisor manipulating memory-mapped I/O routing so that guest memory integrity is lost. Skyfall is tracked as CVE-2026-40671 in AMD-SB-3061, scored 4.9, and is described as incomplete cleanup when a virtual machine fails to launch, which lets guest register data leak through a known class of side channel. A related leak from protected System Management Mode memory has its own identifier, CVE-2026-18448, assigned by the EDK II firmware project.

No workaround is listed, and AMD gives no indication of exploitation in the wild.

The technical picture

SEV-SNP reverses the usual trust model. Normally the hypervisor, the BIOS and their operators can see everything in a VM. A confidential VM keeps its memory encrypted and integrity-protected from the host, and an on-chip security processor signs an attestation report describing the software inside. AMD’s threat model treats the hypervisor and host firmware as untrusted, and both teams worked within it, which is why the results matter despite the privileged starting point.

Mior strikes during platform start-up. SEV-SNP keeps an internal table recording which guest owns each memory page. A host controlling the hypervisor and BIOS, plus a PCIe device, could disrupt how that table was initialised, leaving part of it unprotected. The host could then force debug mode on for a protected guest and read or change its memory, succeeding in all 1,000 attempts according to The Hacker News. In another test, a malicious VM borrowed a harmless VM’s measurement, so attestation vouched for software it was not running. The paper calls this a “violation of all security guarantees afforded by SEV-SNP”. It was demonstrated on a Zen 5 EPYC 9135, still worked with ciphertext hiding enabled, and Zen 3 and Zen 4 parts may also be affected.

Skyfall extends Transient Scheduler Attacks, AMD timing side channels disclosed in July 2025, into a data-sampling technique that the authors say defeats existing mitigations. A hypervisor that deliberately makes a confidential VM fail to launch can sample guest state left behind, and in testing the team extracted saved registers and an encryption key protecting a VM’s disk. It also leaked decrypted microcode and System Management Mode data. The team showed it on Zen 3 and Zen 4 but not Zen 5, though AMD lists Zen 5 EPYC fixes too. It needs no hardware tampering.

There are limits. Skyfall’s reviewers noted that a real attack needs an idle core, repeated failed launches and a guest that survives them, while Mior’s public code needs a modified BIOS. Neither helps an outsider without host control.

Flow diagram showing how the Mior and Skyfall attacks let a malicious cloud host get past AMD SEV-SNP protections, and how fixes arrive

Why it matters for UK organisations

Confidential computing promises that you can run sensitive work on someone else’s hardware without trusting the operator. UK organisations use it for regulated financial data, health records, keys, AI model weights and multi-party data sharing. Attestation is often the evidence shown to auditors, regulators and partners.

Mior undermines exactly that evidence: if a hostile host can make a tampered VM look clean, key-release services and controls resting on attestation alone are weaker than assumed. Skyfall targets in-memory secrets, the very thing confidential VMs exist to guard.

The realistic adversary here is not a ransomware crew. It is a rogue insider at a hosting provider, a well-resourced state actor that has compromised a provider’s management plane, or a smaller provider with weak firmware controls. With the Cyber Security and Resilience Bill set to bring managed service providers and data centres further into regulatory scope, the question of how far you can trust your host’s firmware is becoming a governance issue as well as a technical one.

Expert view

This is strong offensive research, best read in proportion. Neither attack hands an outsider a foothold. Both start from the position confidential computing was designed to resist: the host itself turning hostile. If your threat model never included your provider, the practical impact on you is small. If it did, and that was the reason you paid a premium for confidential VMs, these papers deserve a proper read.

In my experience, the weak point in confidential computing is rarely the cryptography. It is the assumption that attestation is checked rigorously and kept up to date. When we review these environments, attestation has often been configured once, the expected firmware baseline never updated, and nobody tasked with rejecting hosts that fall behind. The Mior bulletin publishes fresh TCB values to pair with each patched firmware release. That is the practical lever, but only if someone enforces it.

Patching is the other problem. AMD’s SEV firmware and microcode are dated 12 August, but platform firmware is targeted for November and December, embedded fixes run into 2027, and nothing reaches you until your provider installs its vendor’s BIOS update. Tenants cannot patch this themselves.

What to do now

  1. Inventory your confidential workloads. List every SEV-SNP confidential VM you run or rely on, its EPYC generation (7003, 8004, 8005, 9004 or 9005 series) and the data or keys it protects.
  2. Ask your providers direct questions. When will the November and December platform firmware be applied to the hosts running your workloads? Will they confirm it in writing? How do they control and log who can change host BIOS and hypervisor configuration?
  3. Tighten attestation policy. Once fixes land, require the updated TCB values from AMD’s bulletins in your attestation checks and key-release policies, and reject hosts that report older ones. Make someone responsible for keeping those values current.
  4. Do not rely on attestation alone. For the most sensitive secrets, add layers that do not depend on the host: short-lived keys, external key management with strict release conditions, and monitoring for unexpected VM launch failures where your provider exposes them.
  5. Patch your own estate. If you operate EPYC servers yourself, track your server vendor’s BIOS and BMC releases for these CVEs and treat firmware as part of your secure configuration and security update management, in line with the Cyber Essentials controls.
  6. Update risk records. Record the residual risk in supplier assessments until providers confirm remediation, and revisit any compliance claims that rest on confidential computing.

Bottom line

Mior and Skyfall do not make confidential computing pointless, but they puncture the idea that it removes the need to trust your provider. For now, your protection is only as good as your host’s firmware patching and your own attestation discipline. UK organisations that depend on SEV-SNP should get remediation dates from their providers in writing and enforce the new firmware baselines once available.

Sources

Related Posts