DDRop Attack Breaks TDX & SEV-SNP: 2026 UK Guide

What DDRop actually breaks

Confidential computing platforms such as Intel TDX, Intel Scalable SGX and AMD SEV-SNP exist to keep a virtual machine's memory encrypted and isolated even from the host operator or hypervisor. DDRop, disclosed on 14 September 2026, is a hardware-level attack that allows an attacker's VM to remap its memory onto arbitrary physical addresses and then read or change protected memory belonging to a victim virtual machine, because the CPU fails to check whether the data it is reading back is genuinely fresh rather than an old, replayed copy.

This is not a software patchable logic bug in an application — it sits in how the memory-encryption engine tracks and verifies data, which is precisely the layer buyers were told to trust when they moved sensitive workloads into confidential VMs.

How the impact differs between Intel and AMD

The disclosure does not treat every affected platform identically. On AMD SEV-SNP, the attack leverages the page-relocation feature to copy data between victim pages within the broader freshness-check weakness. On Intel TDX, researchers also demonstrate a debug-mode attack and an attestation-forgery attack that are specific to Intel's TDX implementation. Attestation forgery is the more concerning of the two for procurement teams, because attestation is the mechanism buyers rely on to prove — to an auditor, a regulator, or a client — that a workload really is running inside a genuine, unmodified confidential enclave.

Independent reporting from The Register characterizes the mechanism as a failure to verify memory freshness, enabling replay of stale attacker-selected data into a protected VM's memory. Media coverage credits researchers affiliated with KU Leuven, ETH Zurich, Durham University, and Google.

The physical-access caveat — and why it shouldn't be dismissed

AMD told The Hacker News that because the attack requires physical access to the system, it falls outside the scope of the published SEV/SNP threat model. That is a defensible engineering answer, but it is not a reason for UK buyers to close the ticket. Confidential computing is often positioned for organisations that may not fully trust the physical operator of the server — colocation tenants, cloud customers on shared infrastructure, and regulated firms placing sensitive data with third-party data centre providers. For that exact buyer, 'requires physical access' describes the threat model they were trying to defend against, not one they can safely ignore.

Anyone using confidential VMs precisely because they cannot vouch for who has hands on the rack — insiders, data centre staff, or a compromised supply chain partner — needs to treat DDRop as squarely inside scope, whatever the vendor's public threat-model framing says.

Why this matters for UK infrastructure buyers now

No CVE identifier or CVSS score appears in the articles and reports available at the time of writing, which makes this an unusually awkward one to slot into standard vulnerability scoring and patch-cycle processes. Procurement and security teams should not wait for a formal CVE before acting: the absence of a score is itself a governance gap that needs to be logged and tracked through your existing process for managing hardware vulnerabilities.

Any organisation currently running, or evaluating, confidential VMs on Intel and AMD processors for regulated workloads, client data isolation, or multi-tenant hosting should now audit your threat model against the specific claim in this disclosure: that memory isolation and attestation can be broken by someone with physical or privileged access to the host. That includes rechecking assumptions baked into contracts with cloud and colocation providers about who has physical custody of hardware running confidential workloads.

Practical steps while the picture firms up

Until vendor guidance and any formal identifier land, treat DDRop as a physical-access and supply-chain control issue rather than a purely remote software one.

Given that attestation forgery on Intel TDX is called out specifically, any process that relies on remote attestation to prove workload integrity to a third party — a regulator, an auditor, a client — should be reviewed for how much weight it places on attestation alone versus other zero trust controls layered on top.

• •Inventory every workload currently relying on Intel TDX, Intel Scalable SGX or AMD SEV-SNP for its security guarantees
• •Re-verify physical access controls, personnel vetting and chain-of-custody at any site hosting confidential VMs, including third-party colocation and cloud
• •Flag attestation-dependent compliance processes for manual review pending vendor guidance
• •Fold DDRop into ongoing managed detection and response and broader broader cybersecurity solutions planning rather than treating it as a one-off patch item
• •Cross-reference with related platform hardening work, including server BMC firmware security, since physical-access attacks often chain through management interfaces