Researchers attack AMD's Infinity Fabric to bypass hardware security protections with 'Fabricked'

At a glance:

• Critical flaw in AMD's Infinity Fabric lets malicious cloud hosts silently read and write to protected VM memory.
• Attack, named "Fabricked," bypasses SEV-SNP attestation, allowing forged security reports on Zen 3/4/5 EPYC chips.
• AMD issued patches under CVE-2025-54510; cloud providers must deploy firmware updates to mitigate.

The Architecture of Trust, and How It Fails

Confidential computing is designed to solve a fundamental cloud security paradox: tenants must entrust their most sensitive workloads to infrastructure they do not control. AMD's Secure Encrypted Virtualization with Secure Nested Paging (SEV-SNP) is a cornerstone technology promising hardware-enforced isolation for virtual machines. It uses a dedicated security processor, the Platform Security Processor (PSP), to encrypt memory and manage a Reverse Map Table (RMP) that dictates which entities can access which pages. The entire system is validated through cryptographic attestation, allowing a tenant to verify that their cloud environment is genuine and untampered before loading critical data. The newly disclosed "Fabricked" attack demonstrates that this chain of trust can be broken not through a complex software bug, but by subverting a low-level hardware interconnect—the Infinity Fabric—during the boot process.

The Weak Link: UEFI Firmware and the Infinity Fabric

AMD's threat model explicitly assumes the Unified Extensible Firmware Interface (UEFI), controlled by the cloud provider, is untrusted. This is why SEV-SNP relies on the PSP to establish a secure baseline. However, researchers at ETH Zurich discovered that the UEFI is responsible for issuing two critical PSP API calls that lock down the Data Fabric configuration registers within the Infinity Fabric after initialization. A malicious or compromised UEFI can simply skip these calls, leaving the memory routing layer writable even after SEV-SNP is supposed to be active. This alone is a significant oversight, but the attack's elegance lies in its second component. The researchers found that during the PSP's initialization, its memory requests were checked against Input/Output Memory Management Unit (MMIO) routing rules—rules intended for hardware device communication—before the standard DRAM routing rules were applied. By configuring these MMIO mappings to shadow the region where the RMP is meant to be created, the attacker can cause the PSP's writes to the RMP to be silently discarded. The system believes the RMP is initialized and secure, but it is an empty shell under the hypervisor's control.

Two Devastating Exploits from a Single Flaw

The uninitialized RMP grants the hypervisor god-like permissions over the Confidential Virtual Machine (CVM). The researchers demonstrated two concrete, high-impact exploits. First, they could enable debug mode on a production CVM after a valid attestation report had been generated. This allows the hypervisor to decrypt and read arbitrary VM memory at will, completely undetected by the guest operating system. Second, and perhaps more insidiously, they could forge attestation reports wholesale. A malicious VM image, loaded on a compromised platform, could present a cryptographic report that appears identical to one from a genuine, secure SEV-SNP environment. This breaks the foundational verification step, meaning a tenant could be tricked into loading their secrets into a compromised system. The attack is fully deterministic, requires no physical access, and succeeds 100% of the time on vulnerable platforms, as presented in their USENIX Security 2026 paper.

Scope, Response, and Remediation

The researchers confirmed the exploit on AMD's latest Zen 5 EPYC processors. In a move suggesting broader systemic issues, AMD's subsequent security advisory (AMD-SB-3034) also listed firmware updates for Zen 3 and Zen 4 architectures, indicating the vulnerability's roots may extend across multiple generations. Following responsible disclosure in August 2025, AMD assigned the flaw CVE-2025-54510 and published guidance once the embargo lifted in April 2026. The company has issued patches covering Zen 3, Zen 4, and Zen 5 platforms. The impact is narrowly constrained to environments actively using SEV-SNP confidential computing. Standard cloud workloads and home users not relying on these specific hardware-based isolation features are unaffected. For organizations leveraging AMD EPYC-based confidential computing instances—particularly in public cloud settings—the imperative is clear: verify with their cloud provider that the necessary firmware updates have been deployed to lock down the Infinity Fabric configuration and prevent this class of boot-time subversion.

A Wake-Up Call for Hardware-Based Security

"Fabricked" is more than a single vulnerability; it is a case study in the immense complexity of trusted computing. It exposes how security can hinge on the correct configuration of components—like the Infinity Fabric—that are typically hidden from view and assumed to be static. The attack flow, from a malicious firmware decision to a complete bypass of cryptographic attestation, underscores that hardware isolation is only as strong as its weakest initialization link. While AMD's response with cross-generational patches is commendable, the episode serves as a stark reminder for the industry. As confidential computing becomes a mainstream offering from all major cloud providers and CPU vendors, the assumptions baked into their threat models must be rigorously stress-tested. The next frontier of hardware security will require not just secure processors, but verifiable, tamper-evident boot pathways that can guarantee the integrity of every interconnect and configuration register from the moment power is applied.