Researchers unveil Fabricked, a software attack that misroutes Infinity Fabric to break AMD SEV-SNP

Why it matters

Startups increasingly anchor trust on confidential VMs for data-in-use protection. Fabricked shows SEV-SNP’s guarantees can fail if platform firmware misconfigures Infinity Fabric, so founders need to verify cloud and OEM firmware posture before promising customers strong isolation.

A research team has published Fabricked, a new software-only attack on AMD SEV-SNP that manipulates the Infinity Fabric to compromise Confidential VMs. In a detailed project site and forthcoming USENIX Security 2026 paper, the authors describe how a malicious hypervisor can misroute memory transactions so the platform security processor (PSP) fails to fully initialize SEV-SNP while reporting success.

How Fabricked works

The researchers start from SEV-SNP’s confidential computing threat model, where the cloud provider’s UEFI/BIOS is untrusted. AMD delegates parts of the Infinity Fabric configuration to firmware at boot. According to the project summary, if an attacker-controlled UEFI skips the API calls that lock down certain fabric settings, the Infinity Fabric remains reconfigurable even after SEV-SNP is activated.

With that foothold, a malicious hypervisor can change fabric routing to re-route DRAM transactions. Because the PSP is also connected over the fabric, its reads and writes can be misdirected. The team identifies a critical window during SEV-SNP initialization when the PSP sets up the Reverse Map Table (RMP), which enforces memory access control for CVMs. By corrupting routing rules before those writes, the attacker can cause the PSP’s RMP writes to be dropped. The result: the RMP remains in its insecure default state, as set by the hypervisor, while the system believes initialization succeeded. When CVMs subsequently launch, the hypervisor can perform arbitrary reads and writes in their address space, breaking SEV-SNP’s core guarantees.

The authors characterize Fabricked as deterministic, software-only, and not dependent on any code inside the victim CVM or on physical access. They provide a technical deep dive and figures in the paper, along with proof-of-concept code in a public GitHub repository.

What went wrong

Per the write-up, Fabricked relies on two issues: first, that a hypervisor can maliciously corrupt certain Infinity Fabric routing rules; second, that when the PSP issues memory requests, the corrupted rules silently take precedence over the correct ones, allowing crucial initialization writes to be misdirected without detection.

What hardware is affected

The team says they confirmed the vulnerability on AMD Zen 5 EPYC processors running SEV-SNP. They add that an AMD advisory lists firmware updates for Zen 3 and Zen 4 as well. Specific mitigations or patches are not detailed on the site, but the implication is that firmware must correctly lock down fabric configuration before SEV-SNP initialization and ensure PSP writes cannot be bypassed by later routing changes.

Why founders should care

Confidential computing is increasingly part of the security story for startups handling regulated or sensitive data in multi-tenant clouds. If you rely on SEV-SNP-backed Confidential VMs for data-in-use isolation, Fabricked suggests a malicious or compromised host can pierce that boundary by abusing platform initialization and fabric routing. Until platform vendors and cloud providers apply the right firmware updates, treat SEV-SNP guarantees as contingent on correct fabric lock-down and verified PSP initialization.

The Fabricked site links the paper to USENIX Security 2026 and publishes code, signaling that cloud, motherboard, and OEM firmware teams will be moving quickly. Founders building on confidential compute should track advisories and maintenance windows for SEV-SNP platforms closely.