As reported by The Hacker News, researchers from ETH Zurich have publicly demonstrated two attacks—dubbed Mior and Skyfall—that break the isolation guarantees of AMD's SEV-SNP confidential computing technology on EPYC server processors. While both attacks require a privileged attacker position (hypervisor control, and for Mior, BIOS/UEFI control plus a PCIe device), they expose a fundamental crack in a trust model that cloud providers and regulated enterprises increasingly rely upon.

Security Impact: As reported by The Hacker News, researchers from ETH Zurich have publicly demonstrated two attacks—dubbed Mior and Skyfall—that break the isolation guarantees of AMD's SEV-SNP confidential computing technology on EPYC server processors.

Why This Matters: Attestation Is the Foundation

The most consequential element of the Mior attack isn't the memory read capability—though that alone is serious. It's the attestation report forgery. SEV-SNP's entire value proposition rests on the ability to cryptographically prove to a remote party that a specific VM image is running on legitimate hardware, untampered. If an attacker can substitute a benign VM's measurement into a malicious VM's attestation report, the trust chain collapses. A cloud tenant performing attestation checks would see a clean bill of health while their workload is actually compromised. That's not a data exposure issue—it's a silent integrity bypass.

The attack succeeds not by breaking encryption but by manipulating the metadata that tells the system what's encrypted and who owns it—turning the protection mechanism against itself.

Vulnerability Summary

AttackComponentAffected HardwarePrerequisitesPatch Status
MiorSEV firmware (PSP / RMP manipulation)AMD EPYC Zen 3, Zen 4, Zen 5 (tested on EPYC 9135)Hypervisor + BIOS/UEFI + PCIe device (e.g., GPU)SEV firmware dated Aug 12, 2026; platform firmware expected Dec 2026
SkyfallMicrocodeAMD EPYC with SEV-SNPHypervisor controlMicrocode dated Aug 12, 2026; platform firmware expected Nov 2026
No CVE identifiers were publicly listed in the source reporting at time of publication. Defenders should monitor AMD's product security advisories for formal CVE assignments and severity ratings.

Active Exploitation

Not observed in the wild at time of reporting. Both attacks were demonstrated in controlled lab conditions. Mior achieved 100% success rate across 1,000 test attempts—this is not a theoretical or probabilistic exploit.

Who Is at Risk

Vulnerability Summary
Multi-tenant cloud providers where the host operator is not fully trusted by tenants—exactly the scenario SEV-SNP was designed for
Regulated industries (finance, healthcare, government) relying on confidential computing for compliance isolation
Defense and intelligence workloads running on shared AMD EPYC infrastructure
Any organization using SEV-SNP attestation as a control for supply chain or workload integrity verification

The Practical Constraint vs. Real Threat

Defenders may be tempted to dismiss these attacks due to the high prerequisites—hypervisor and BIOS control plus a physical PCIe device. But that dismisses the core threat model SEV-SNP was built to address: the host operator is the adversary. A compromised or malicious cloud provider, a rogue insider with physical access, or a supply chain attacker who controls firmware all fit this profile. The entire point of confidential computing is to protect against exactly these actors. Saying the attack requires too much privilege misses the purpose of the technology.

Shield53 Recommendations

Immediate Actions

  • Inventory AMD EPYC deployments—identify all servers using SEV-SNP, particularly Zen 3/4/5 generation EPYC processors, and document which workloads rely on attestation
  • Engage server OEMs now—AMD is delivering platform firmware to server manufacturers on different timelines (November for Skyfall, December for Mior). Contact your OEM (Dell, HPE, Lenovo, etc.) to confirm delivery dates for your specific platforms
  • Audit attestation-dependent workflows—if you rely on SEV-SNP attestation for compliance or security decisions, treat current attestation reports as potentially unreliable until patched. Implement compensating controls
  • Restrict physical and firmware access—since Mior requires BIOS/UEFI modification and a PCIe device, tighten physical security controls on host hardware and monitor for unauthorized firmware changes
  • Monitor PCIe device inventory—track and alert on any new or unexpected PCIe devices attached to SEV-SNP hosts, especially GPUs
  • Review confidential computing architecture—for the highest-value workloads, consider whether additional layers of protection (application-level encryption, HSM-backed key management) are warranted as defense in depth

Strategic Considerations

The patching timeline creates a window of exposure: microcode and firmware exist but won't reach end customers through OEMs until November–December 2026 at earliest, and embedded chip fixes come later still. Organizations should assume that any SEV-SNP-protected workload running on unpatched hardware cannot fully trust its attestation chain during this period. Plan accordingly—especially for audit and compliance frameworks that may cite confidential computing as a compensating control.