An AMD SEV-SNP security flaw discovered by ETH Zurich researchers exposes a critical weakness in AMD’s confidential-computing protections for cloud virtual machines. The attack, called Fabricked, manipulates AMD Infinity Fabric routing during system boot to undermine SEV-SNP protections entirely, allowing a malicious cloud provider to read confidential VM memory and forge attestation reports.
Key Takeaways
- Fabricked exploits untrusted UEFI firmware to misconfigure Infinity Fabric before SEV-SNP locks down the system.
- The attack corrupts the reverse map table (RMP), SEV-SNP’s core enforcement mechanism, rendering it ineffective.
- Malicious cloud hosts gain arbitrary read and write access to victim VM memory without physical access.
- Attestation reports can be forged, breaking the trust model for confidential computing in cloud environments.
- AMD was notified in August 2025 and plans to issue a patch.
How the AMD SEV-SNP Security Flaw Works
The AMD SEV-SNP security flaw exploits a fundamental assumption in confidential computing: that once SEV-SNP is activated, the system hardware protections remain locked even if firmware cannot be trusted. Fabricked breaks this assumption by attacking Infinity Fabric, the internal interconnect that connects CPU cores, memory controllers, and the Platform Security Processor (PSP). The researchers identified that UEFI firmware, which cloud providers control, is responsible for locking down Infinity Fabric configuration during boot. By modifying UEFI to skip these lock-down API calls, an attacker leaves Infinity Fabric reconfigurable even after SEV-SNP activation.
Once Infinity Fabric remains configurable, the attacker can manipulate memory routing. During SEV-SNP initialization, the PSP writes critical data to DRAM to set up the reverse map table (RMP), the data structure that enforces confidentiality and integrity protections. By misrouting these PSP-to-DRAM writes to memory-mapped I/O (MMIO) instead, the attacker corrupts the initial RMP so it fails to block malicious accesses from the untrusted hypervisor. The result: when the victim launches confidential VMs on the compromised platform, the hypervisor can access their memory as if the RMP enforcement does not exist.
This is not a hardware defect in the traditional sense. The AMD SEV-SNP security flaw stems from the trust model itself. The researchers exploited the fact that confidential-computing threat models assume UEFI is untrusted and cloud-provider controlled, yet still rely on UEFI to configure critical security hardware correctly. Fabricked exposes the gap between that assumption and reality.
What Attackers Can Do With This Vulnerability
The AMD SEV-SNP security flaw grants attackers multiple capabilities once Fabricked is deployed. First, they obtain arbitrary read and write access within victim VM address space, violating both confidentiality and integrity guarantees. A malicious cloud host can silently exfiltrate encryption keys, databases, or any sensitive data running inside the VM without triggering any detection. Second, attackers can forge attestation reports, which are cryptographic proofs that a VM is running on a legitimate, uncompromised platform. By corrupting the RMP and controlling the PSP’s memory operations, the attacker can generate false attestations that convince external parties the VM is secure when it is not.
Third, the attack enables debugging during victim VM execution, giving the attacker runtime control over the victim’s code. This transforms a read-only data leak into active compromise. For cloud providers offering confidential computing as a trust boundary between tenants, Fabricked means a malicious operator can break that boundary entirely without any hardware modification, firmware replacement, or physical access. The attack is purely software-based, launched from the hypervisor layer.
AMD’s Response and the Patch Timeline
The researchers responsibly disclosed their findings to AMD in August 2025. AMD acknowledged the vulnerability, thanked the researchers for the disclosure, and committed to issuing a patch. However, the source material does not specify the exact timeline or availability date for the fix. This creates a window of exposure for organizations running confidential VMs on AMD EPYC systems with SEV-SNP enabled. Until the patch is deployed, cloud providers and enterprises must assume that any malicious hypervisor operator could potentially exploit Fabricked to compromise confidential workloads.
The vulnerability is particularly concerning because SEV-SNP was designed to protect against exactly this threat: a malicious cloud provider. The AMD SEV-SNP security flaw demonstrates that architectural assumptions can be as critical as code correctness. Even if every line of PSP firmware is perfect, if the boot-time configuration of Infinity Fabric is not properly locked down before the security processor activates, the entire protection collapses.
Why This Matters for Cloud Security
Confidential computing has emerged as a key technology for protecting sensitive workloads in public clouds. Customers running healthcare data, financial records, or AI training on shared cloud infrastructure rely on technologies like SEV-SNP to maintain isolation even if the cloud provider is compromised or malicious. Fabricked undermines that promise. It shows that the boundary between untrusted firmware and trusted hardware is not as clean as the confidential-computing threat model assumes.
The attack also highlights a broader architectural challenge: Infinity Fabric, like any system interconnect, is a critical trust component that must be configured correctly from the moment the system boots. If that configuration can be altered by untrusted firmware, the entire security model fails. This is not unique to AMD—similar interconnect-based attacks could theoretically apply to other platforms if similar misconfiguration windows exist.
Fabricked vs. Other AMD Security Research
The AMD SEV-SNP security flaw disclosed by Fabricked differs from previous AMD security disclosures in its specificity and scope. Rather than attacking a single cryptographic function or memory-protection mechanism, Fabricked targets the configuration of the entire memory fabric, the foundational layer that determines how all memory operations are routed. This gives it exceptional power: once the RMP is corrupted at boot, no software-level fix can restore protection for that VM.
Previous attacks on confidential computing have required either physical access, specific hardware vulnerabilities, or exploitation of side channels. Fabricked requires only what a malicious cloud provider already has: control of the hypervisor and UEFI firmware. That makes it far more practical for a real attacker in a cloud environment than many theoretical attacks that require specialized equipment or privileged access to multiple system layers.
What Organizations Should Do Now
Until AMD releases and deploys the patch, organizations running confidential VMs on AMD EPYC systems should evaluate their risk. If your cloud provider is not trustworthy, or if you are running on a shared cloud platform where the provider could be compromised, confidential computing does not protect you from Fabricked until the patch is applied. This does not mean abandoning SEV-SNP entirely—it means understanding the current window of exposure and planning remediation.
Cloud providers should prioritize patching systems as soon as AMD releases the fix. For customers, the key question is: does your cloud provider have a timeline for deploying the patch, and can they guarantee it will be applied before you deploy new confidential workloads? Until then, the AMD SEV-SNP security flaw remains a real threat to the confidentiality of sensitive data in the cloud.
Will this attack work on all AMD systems?
No. Fabricked specifically targets AMD EPYC platforms running SEV-SNP in confidential-computing deployments. Consumer AMD processors and systems not using SEV-SNP are not affected. The attack requires the attacker to control the hypervisor and UEFI firmware, which is only practical in a cloud environment where the provider is malicious.
Can the patch be deployed without downtime?
The research brief does not specify whether the AMD patch requires system reboots or can be applied live. Organizations should contact their cloud provider or AMD directly for patch deployment details and expected downtime.
Does this affect Intel’s confidential computing?
The AMD SEV-SNP security flaw is specific to AMD’s architecture and Infinity Fabric. Intel’s confidential-computing technologies use different architectures and interconnects, so Fabricked does not directly apply. However, similar misconfiguration vulnerabilities could theoretically affect other platforms if similar boot-time configuration windows exist.
The Fabricked attack is a sobering reminder that hardware-backed security is only as strong as the assumptions underlying its design. The AMD SEV-SNP security flaw exposes a gap between the confidential-computing threat model and the real-world control that cloud providers have over system firmware. Until the patch is deployed and verified, organizations must treat confidential VMs on vulnerable AMD EPYC systems as potentially compromised if the cloud provider is untrusted or could be compromised by attackers.
Edited by the All Things Geek team.
Source: Tom's Hardware
