The interposer needed to carry out the new DDRop attack can be assembled for about $159 and fitted to a server in minutes — and once in place it can make a processor read old, validly encrypted data as if that data had never been changed.
How DDRop works
DDRop is an active hardware interposer attack against DDR5 server memory that silently drops writes so the processor keeps reading prior encrypted contents. The interposer is a small board of switches that sits on the memory bus and runs at full DDR5 speed. To drop a write, it forces an error on the command bus and then cuts the wire the memory module uses to report that error, so the module quietly discards the command and the processor is never told. Because scalable memory-encryption designs omit a freshness guarantee, the encryption engine detects nothing wrong when old ciphertext decrypts correctly.
What DDRop breaks: Intel TDX, Scalable SGX, and AMD SEV‑SNP
The researchers say DDRop works against Intel TDX, Intel Scalable SGX, and AMD SEV‑SNP — the hardware technologies cloud services use to keep customer data private even from the cloud provider. On Intel TDX the team turned write-dropping into full control of a protected virtual machine. By dropping writes the firmware used to set up a new page table wrote empty entries that the interposer suppressed, leaving attacker-chosen data in place. That allowed a malicious virtual machine to map its memory onto arbitrary physical addresses, read and modify protected memory, toggle a victim into debug mode and copy its plaintext memory, and overwrite the launch measurement that attests a machine’s trusted state.
Two of those results — reading a victim’s memory and toggling debug mode — were demonstrated only under TDX’s default “logical integrity” mode. The researchers say Intel’s optional “cryptographic integrity” mode would block those two because they change data owned by another VM. Forging a machine’s own attestation, they argue, would still work under cryptographic integrity because the forgery happens inside the attacker’s VM under its key and the hardware still marks the data as valid; the team could not confirm that point because their test system did not support cryptographic integrity.
On AMD SEV‑SNP the effect was 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 results are specific to Intel TDX.
Audit-ready is a season. It shouldn't be.
Evidence in spreadsheets, controls drifting between audits, frameworks multiplying on flat headcount. Nubivance runs continuous compliance on Rapid7 Cyber GRC - SOC 2, HIPAA, ISO 27001, PCI, CMMC.
End the scrambleHow DDRop differs from earlier interposer work
DDRop is the first active interposer attack the researchers say works against DDR5 in today’s cloud servers and the first to break the integrity of an up‑to‑date Intel TDX system instead of only reading data. Earlier DDR5 interposer attacks such as TEE.fail were passive and required slowing the bus for second‑hand lab equipment; earlier active attacks like Battering RAM only worked on DDR4 because DDR5’s redesigned command format blocks their address‑swapping trick. DDRop gets around that change by dropping writes rather than swapping addresses.
Vendor acknowledgements and limits
The research team at KU Leuven, ETH Zurich, Durham University, and Google disclosed the work to Intel and AMD through coordinated disclosure; both companies acknowledged the findings and said they would issue security bulletins on the disclosure date. AMD told The Hacker News that because the attack requires physical access it falls outside the published threat model for SEV / SNP. Intel has taken the same position on physical attacks against server memory and has said it does not plan to assign such attacks a CVE. Intel has described this research area as “out of scope, but not out of mind.”
Intel also notes its optional cryptographic‑integrity mode already blocks part of DDRop and that the company is working on stronger memory‑encryption designs for future chips. One proposed approach, called cache‑line versioning, would add a freshness check to the memory bus; the researchers say it is unclear whether that proposal would stop DDRop and Intel has not said whether it would.
What this means for cloud providers, security teams, and regulators
- Cloud providers (AWS, Microsoft Azure, Google Cloud): The affected technologies are offered by major cloud platforms, and DDRop shows that an attacker with brief physical access and control of server software could undermine in‑use confidentiality. Providers will need to consider physical access controls, supply‑chain protections, and detection of tampering such as interposer checks at boot.
- Security and operations teams: The researchers suggest software mitigations can raise the bar — restrict the memory‑management features DDRop abuses, check that important writes actually landed, and look for an interposer during boot — but they stress there is no simple patch because the root cause is a hardware design that omits freshness checks.
- Regulators and procurement leaders: Because the attack requires a brief physical visit, the researchers note plausible vectors include a rogue data‑center employee, supply‑chain tampering, or hardware seized under legal compulsion, all of which implicate physical‑security and procurement controls.
The researchers will present DDRop at the ACM CCS 2026 conference in November and are releasing interposer board designs, controller firmware, and attack code on GitHub alongside their paper. They told The Hacker News they have no evidence of DDRop or a comparable active interposer being used outside the laboratory. AMD’s bulletin on DDRop was scheduled for publication on its product security page later on September 14; Intel did not respond to a request for comment before publication.
For now, the clearest fact is also the most unsettling: scalable memory encryption in current server hardware protects confidentiality but, by design, does not prove freshness. DDRop turns that intentional omission into a practical, low‑cost way to make a cloud server read yesterday’s (and still validly encrypted) memory as if it were today’s — and it takes only a few minutes and a board that costs less than $200 to try.
