TL;DR
- what: Researchers at KU Leuven, ETH Zurich, Durham University, and Google disclosed DDRop, a DDR5 interposer that drops memory writes so the processor keeps reading stale encrypted data as if it were current.
Researchers have broken the memory integrity guarantees of Intel TDX, Intel Scalable SGX, and AMD SEV-SNP with a circuit board that costs under $200 to build. The attack, called DDRop, was disclosed on September 14, 2026 by a team from KU Leuven, ETH Zurich, Durham University, and Google. It does not crack the encryption engine or extract a key. It makes memory writes disappear, and the processor never finds out.
On an up to date Intel TDX host, that was enough to read a victim virtual machine's private memory, flip that machine into debug mode, copy it out in plaintext, restore the original contents so the victim showed no sign of tampering, and forge the launch measurement a confidential VM presents to a remote customer as proof it booted in a trusted state.
The freshness gap
Confidential computing keeps server memory encrypted so that anyone with physical access, including the cloud provider, sees only scrambled data. To cover the hundreds of gigabytes a modern server carries, these designs give up a property called freshness. The processor can confirm that a memory line is encrypted. It cannot confirm that the line holds the most recent value written to that address, and stale ciphertext still decrypts cleanly.
DDRop turns that tradeoff into an attack. The interposer is a small board of switches that sits on the DDR5 bus between the processor and a memory module and runs at full bus speed. To kill a write, it forces an error on the command bus, then cuts the wire the module uses to report that error. The module silently discards the command, the processor is never told, the old value stays put, and it reads back as current.
Why DDR5 was supposed to be out of reach
Earlier DDR5 interposer work, including TEE.fail, was passive. It listened to the memory bus and had to slow the bus down to keep second hand lab equipment in sync. Active attacks that changed what the memory saw, such as Battering RAM, only worked on older DDR4, because DDR5's redesigned command format defeats the address swapping trick they relied on. DDRop is the first active interposer attack to work at DDR5 speeds, and the first to break the integrity of a current Intel TDX system rather than only read data from it. The team is releasing board designs, controller firmware, and attack code on GitHub alongside the paper, which is due at ACM CCS 2026 in November.
From dropped writes to full guest control
TDX keeps each guest's page tables encrypted and under the control of trusted firmware. When that firmware writes empty entries to set up a new page table, DDRop drops those writes, so the table instead retains attacker chosen data planted in that memory beforehand. The attacker's own virtual machine can then map its address space onto any physical address and read or modify protected memory. With that primitive the researchers pulled a victim's private memory, switched the victim into debug mode for a plaintext dump, and rolled the memory back afterward.
Two of the three TDX results depend on the default mode — Reading another guest's memory and toggling debug mode were demonstrated only under logical integrity, which is TDX's default. Cryptographic integrity, the optional stronger mode, would block both, because each involves changing data owned by a different VM. The researchers' test platform did not support that mode, so the boundary is argued rather than measured.
Attestation is the finding that scales
The attestation forgery is what architects should sit with. The researchers overwrote the launch measurement a VM uses to prove its state to a remote relying party. Because that write lands inside the attacker's own VM and under its own key, the hardware still marks the data valid. The team argues this survives cryptographic integrity as well, since that mode adds no freshness check and cannot tell reused contents from fresh ones. They could not confirm it on their hardware. If it holds, a machine the attacker controls can pass as a trusted one, and every secret release gated on that measurement is gated on nothing.
On AMD SEV-SNP the result is narrower. Dropping writes during AMD's page relocation feature let the researchers copy the contents of one victim page into another. The debug mode and attestation forgery attacks are specific to Intel TDX. All three technologies encrypt memory without the freshness check DDRop exploits, so all three are in scope.
What is not affected
- Intel Client SGX, used in some desktop and laptop chips, is not affected: it uses a hardware integrity tree that catches stale data. Intel has since retired it.
- NVIDIA confidential computing GPUs are not affected, because their memory sits inside the chip package where an interposer cannot be fitted.
- Arm CCA was not tested, and the researchers say it may be affected too.
- Home computers and phones are not the target. The attack is aimed at cloud and colocation servers running TDX, Scalable SGX, or SEV-SNP.
No patch, and what to do about it
There is nothing to install. The weakness is in the hardware design, and closing it for good needs new memory encryption silicon that provides integrity and freshness together. Software can raise the cost without removing the root cause: restrict the memory management features DDRop abuses, verify that important writes actually landed, and stop treating an attestation quote as proof on its own.
The threat model is specific. DDRop needs an attacker who already controls the host software stack and can get hands on the machine long enough to seat a board between the processor and a DIMM. The researchers told The Hacker News they have no evidence of DDRop or any comparable active interposer being used outside a laboratory, and no cloud service has been shown to be compromised. What changed on September 14 is that the physical tamper assumption underneath AWS, Azure, and Google Cloud confidential computing now has a $200 counterexample with public board files.
⚠️ Your risk concentrates where you do not own the rack — If your confidential VMs run in a hyperscaler region, physical access is the provider's problem and their datacenter controls apply. If you run TDX or SEV-SNP in colocation, at the edge, or on hardware a third party services, an operator with a badge and ten minutes is now inside the threat model, and your attestation quotes are the first thing to stop trusting blind.
grep -o -m1 sev_snp /proc/cpuinfo
cat /sys/module/kvm_amd/parameters/sev_snp
cat /sys/module/kvm_intel/parameters/tdx
sudo dmesg | grep -iE 'tdx|sev-snp|memory encryption'
cat /sys/devices/system/edac/mc/mc*/ce_count
Originally published on RedEye Threat Intelligence.
Top comments (0)