Security1 publisher2 min readPublished
DDRop silently drops DDR5 writes so Intel TDX reads stale memory as current
Confidential computing never promised memory freshness. DDRop turns that omission into arbitrary access inside a TDX guest, using a board that costs under $200 and two prerequisites a cloud provider already holds.
The Watch · Security desk
What happened
- DDRop drops writes on the memory bus so the processor keeps reading old encrypted data as current, and it works against Intel TDX, Intel Scalable SGX and AMD SEV-SNP.
- The attacker needs software control of the server plus brief physical access to fit an interposer between the processor and a memory module, and the board costs under $200 to build.
- On Intel TDX the team dropped the firmware writes that zero a new page table, leaving attacker-planted data in it and letting their own virtual machine map onto any physical address.
- They read a victim virtual machine, switched one into debug mode to copy its memory in plaintext, and overwrote the launch measurement a guest uses to prove it booted into a trusted state.
- KU Leuven, ETH Zurich, Durham University and Google present the work at ACM CCS 2026 in November, and the team says board designs, controller firmware and attack code are going to GitHub.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- exposure Both prerequisites belong to the cloud provider and to anyone else who can reach the rack, and privacy from the provider is the promise these features were sold on.
- constraint The strongest TDX setting an operator can turn on still has no freshness check, so a configuration change cannot answer the forged launch measurement.
- capability An active interposer that holds DDR5 at full bus speed is now demonstrated, where the previous active work stopped at DDR4 and the DDR5 attacks could only listen.
- decision Anyone who moved regulated data into a TDX or SEV-SNP tenancy on the strength of remote attestation has to defend that control to auditors with physical security, not with the quote.
The processor cannot see a dropped write. The interposer forces an error on the command bus, then cuts the wire the module uses to report that error, so the DIMM quietly discards the command and nothing comes back [6]. The previous value stays in place, correctly encrypted, and the memory encryption engine finds nothing wrong [7].
Freshness was left out to cover the amount of memory a cloud server carries: TDX, Scalable SGX and SEV-SNP verify that memory is encrypted without verifying that it holds the most recent value written, and stale ciphertext still decrypts cleanly [5]. The researchers say DDRop is the first active interposer attack against the DDR5 memory in current cloud servers, and the first to break the integrity of an up-to-date TDX system instead of only reading out of it [8].
DDR5 had been holding: TEE.fail and the other DDR5 interposers were passive listeners that had to slow the bus down to work with second-hand lab equipment [9]. The active attacks that changed what memory saw, Battering RAM among them, ran on DDR4, and DDR5's redesigned command format blocks the address-swapping they relied on [10]. DDRop's board of switches sits on the bus and runs at full DDR5 speed [11].
Two of the three TDX results came only from the default mode, logical integrity. The researchers say TDX's optional cryptographic integrity would block both, because each one writes to data belonging to another virtual machine [18][22]. Their case for the forged launch measurement surviving the stronger mode is that the write happens inside the attacker's own VM, under its own key, so the hardware still marks the data valid, and cryptographic integrity adds no freshness check of its own [19]. That result they did not run: their test system did not support the mode [19].
After switching a victim machine into debug mode and copying its memory in plaintext, the team restored the original contents, and the victim showed no sign of tampering [16]. A TDX quote tells a remote customer which state the guest launched in [17]; whether the ciphertext the CPU read a moment ago is the current version sits outside what the hardware checks [5].
On SEV-SNP the result is smaller: dropping writes during AMD's page-relocation feature let the researchers copy one victim page's contents into another [20]. The report does not include comment from Intel or AMD [23].
What to watch
- Whether Intel or AMD publishes guidance, and whether it goes beyond telling operators to enable TDX cryptographic integrity.
- Whether anyone reproduces the forged launch measurement on a system that supports cryptographic integrity, the one result the team could not run.
- The GitHub release of board designs, controller firmware and attack code ahead of the November CCS presentation.