Fabricked: Misconfiguring Infinity Fabric to Break AMD SEV‑SNP

Confidential computing promises that cloud tenants can run sensitive workloads on remote hardware without trusting the cloud provider. AMD’s Secure Encrypted Virtualization‑Secure Nested Paging (SEV‑SNP) is a hardware‑based trusted execution environment that underpins this promise on EPYC servers. A new paper presented at USENIX Security 2026, Fabricked: Misconfiguring Infinity Fabric to Break AMD SEV‑SNP (​PDF), shows how a malicious hypervisor can undermine SEV‑SNP by tampering with the Infinity Fabric, AMD’s internal interconnect.

---

The problem SEV‑SNP tries to solve

In a typical cloud stack, the host operating system and hypervisor have full visibility into a guest VM’s memory. SEV‑SNP adds a secure co‑processor (the Platform Security Processor, PSP) that encrypts VM memory and enforces a hardware‑level mapping called the Reverse Map Table (RMP). The RMP tells the PSP which physical pages belong to which confidential VM and blocks any unauthorized access. If the RMP is correctly initialized, a rogue hypervisor cannot read or modify a CVM’s memory.

Infinity Fabric: the glue inside AMD CPUs

Modern AMD server chips are built from multiple dies linked together by the Infinity Fabric. This fabric routes memory requests between CPU cores, memory controllers, and the PSP. Because system configurations differ, the firmware (UEFI/BIOS) must program routing tables on every boot. The routing logic lives in the fabric itself, not in the PSP, which means the PSP trusts the fabric to deliver its memory operations to the correct DRAM locations.

How Fabricked works

1. UEFI is assumed untrusted – In the confidential‑computing threat model, the firmware is controlled by the cloud provider. The researchers show that the firmware is responsible for locking down a subset of the fabric’s routing tables during boot.
2. Skip the lock‑down – By modifying the UEFI image, an attacker can omit the API calls that lock those tables. The fabric remains configurable even after SEV‑SNP is enabled.
3. Redirect PSP writes – A malicious hypervisor then rewrites the fabric’s routing entries so that any write the PSP makes to DRAM is sent to a different address.
4. Corrupt RMP initialization – During the SNP_INIT sequence, the PSP writes the RMP entries to DRAM. Because the writes are misrouted, the intended RMP stays at its default, insecure state. The PSP believes the initialization succeeded.
5. Gain unrestricted access – When a tenant later launches a confidential VM, the hypervisor can read and write its memory because the RMP enforcement is effectively disabled.

The attack is purely software‑based, requires no code inside the guest, and succeeds with deterministic 100 % probability on the tested hardware.

Affected hardware and scope

The authors verified the exploit on AMD Zen 5 EPYC processors running SEV‑SNP. AMD’s advisory (​AMD SB‑3034) lists firmware updates for Zen 3 and Zen 4 that address the same misconfiguration, indicating the vulnerability spans three generations of EPYC CPUs. The associated CVE is CVE‑2025‑54510.

Why this matters beyond SEV‑SNP

• Cloud‑provider trust assumptions – The attack shows that a provider‑controlled firmware layer can subvert hardware isolation mechanisms, a scenario that many threat models consider out of scope.
• Potential impact on other TEEs – While the paper focuses on AMD, the underlying principle—misrouting memory requests through a shared interconnect—could be relevant to other chiplet‑based designs, such as Arm CCA or Intel TDX, if similar routing tables are exposed to firmware.
• Firmware update cadence – Mitigations require firmware patches that lock down the fabric before SEV‑SNP activation. Operators must verify that their host firmware includes the fix before offering confidential VMs.

Response from AMD

AMD acknowledged the issue after coordinated disclosure (initial contact on 3 August 2025, embargo lifted 14 April 2026). The company released a security bulletin, updated firmware for affected platforms, and assigned CVE‑2025‑54510. No public statement suggested a hardware redesign; the fix is purely a firmware lock‑down.

What cloud users should do now

1. Check firmware version – Verify that the host’s BIOS/UEFI includes the patch referenced in AMD SB‑3034.
2. Validate SEV‑SNP state – Use the sevctl tool to query the SNP status and confirm that the RMP is properly initialized.
3. Consider alternative TEEs – If the provider cannot guarantee the patched firmware, evaluate other confidential‑computing solutions that do not rely on the Infinity Fabric, such as Intel TDX or Arm CCA, while keeping in mind their own trust assumptions.

Looking ahead

Fabricked illustrates how a seemingly peripheral component—memory routing logic—can become a powerful attack surface when the firmware is under the attacker’s control. As chiplet architectures become more common, security audits will need to extend beyond the cores and co‑processors to the interconnect fabric itself. Future designs may benefit from hardware‑enforced immutability of routing tables after secure‑boot, reducing reliance on firmware correctness.

---

For a deeper technical walk‑through, see the full USENIX paper and the accompanying source code released by the authors on GitHub: fabricked‑attack.