DDRop exposes vulnerability in Intel and AMD encrypted memories with DDR5 interposer

Researchers at KU Leuven, ETH Zurich, Durham University and Google have revealed a hardware attack, named DDRop, which can invalidate the memory protection used by "confidential computing" technologies on servers with Intel and AMD processors. In the laboratory, the authors demonstrate that a small interposer - a circuit plate that is inserted between the CPU and a DDR5 memory module - can rule out scriptures in the memory quietly, so the CPU continues to read old encrypted data as if they were the most recent. According to the team, the interposer and firmware design cost less than $200 in pieces and can be installed in a few minutes.

Confirmed facts: researchers have published (according to their coordinated disclosure) concept tests that work on DDR5 and show impact on Intel TDX (in its default mode, called "logical integrity") and on AMD SEV-SNP; the attack acts by removing writing commands between the CPU and the DRAM, without breaking the encryption or activating the existing checks; the authors are releasing designs, firmware and code in GitHub and will present the work at the ACM CCS 2026 conference. It is also confirmed that the technique requires (1) control of the software of the attacked machine and (2) short physical access to place the interposer; researchers say they have no evidence of use in the real world outside the laboratory.

How it works technically: the encrypted memory architectures that use cloud-reliable enclaves or domains protect memory confidentiality but, to scale up large amounts of RAM, give up a guarantee called fresh(current content). The cipher and its metadata check cryptographic integrity according to keys, but do not verify that the read value is the last writing made by the CPU; therefore an old valid copy continues to decipher correctly. The interposer designed by the researchers operates as a high-speed switch on the DDR5 bus: to rule out a writing, it induces a logical failure in the command signal and then blocks the return line that the memory would use to report that failure, causing the DRAM module to ignore the order without being detected by the CPU. The result is that an alleged update does not reach the DRAM and subsequent readings return the above content.

What this allows in practice: in Intel TDX, the computer transforms that lack of writing into an effective control of the protected domain. By preventing the firmware from writing null entries on a new page table, the attacker causes the table to keep previous data controlled by it; under this condition, an attacking virtual machine can map physical addresses arbitrarily and access or modify protected memory from another VM, read its private content and even change the "launch measurement" used for remote warning. In their experiment the researchers also managed to activate the debug mode of a victim VM and copy their memory in clear, then rewriting the values so as not to leave trace. In AMD SEV-SNP the impact showed was more limited: the attacks focused on page relocation operations, allowing to copy one victim page into another; the techniques of altering attentions or activating debug are Intel specific according to the report.

Confirmed aspects vs uncertain: it is verified that DDRop works in laboratory on DDR5 equipment and exploits the absence of freshness in scalable memory encryption solutions; it is also confirmed that the optional Intel mode known as "cryptographic integrity" blocks some variants of the attack (those that affect pages belonging to another VM), although researchers could not prove that modality because their test system did not support it. It's left uncertain if the cryptographic mode would stop all reasonable variants (the authors point out that the falsification of a own attest could still be possible because it happens under the attacker's key) and if future design proposals such as "cache-line versioning" would prevent DDRop: the researchers say it is not clear.

To whom it affects: mainly loads on datamenters using Intel TDX, Intel scalable SGX and AMD SEV-SNP offered by large clouds (for example, services in AWS, Azure or Google Cloud that advertise confidential computing technologies). The attack is not directed at domestic or mobile PCs and does not affect chips where the memory is physically locked within the package (e.g. GPUs with on-package memory), or the old SGX Client that does have an integrity tree that prevents obsolete data. It may also not apply to other architectures (the authors did not test Arm CCA and consider it potentially affectable).

Real consequences and risks: DDRop does not show that cloud suppliers have been broken, but it states that an attacker with administrative access to the server software and a short physical access (a malicious operator in the dataenter, handling in the supply chain or hardware involved) could violate the guarantees of confidentiality and integrity of enclaves. The impact varies with the security mode activated in each CPU: in TDX logical mode critical attacks are shown; in cryptographic mode the risk is reduced but does not disappear completely.

What stakeholders and users should do: first, cloud operators must review physical and supply chain controls, strengthen policies for access to racks and DIMMs, monitor physical handling and add hardware inspections during maintenance. Technically, they should enable all cryptographic integrity options available on their platforms and provide support for future mechanisms that provide freshness on the memory bus. It is also appropriate to implement interpose detection in the server boot process and to validate that critical scriptures have been applied (whenever feasible).

For cloud customers and developers: do not assume that the trust of the enclave is absolute against physical attacks. Ask your provider whether the cryptographic integrity modality is enabled in the services they hire and whether there are physical protection and supply chain measures. In addition, they strengthen layer safety: encryption at the application level, key rotation, minimize sensitive data in persistent memory, isolation of critical workloads and cross-attestation with policies that detect discrepancies in launch measurements.

Immediate practical measures for managers and managers: require the cloud to enable cryptographic mode when available, audit physical maintenance processes, limit privileges to install low-level access software, and apply integrity tests and write checks in critical memory components. Chips manufacturers (Intel / AMD) have been informed; historically both have considered physical attacks by interposing outside the standard threat model, so complete mitigation will probably require hardware changes in future generations.

Additional useful information and context sources: the conference where the work will be presented (ACM CCS) is the main forum for computer security ( https: / / www.sigsac.org / ccs /) and the technologies of confidential computing are coordinated by consortia of the sector ( https: / / confidentialcomputing.io /). For official references on the family of technologies concerned, see AMD documentation on SEV ( https: / / www.amd.com / en / technologies / sev) and the public notes of manufacturers when they publish their bulletins on the date of disclosure.

Conclusion: DDRop shows a model vulnerability - not a failure of implementation - in current large-scale encrypted memory solutions: the lack of freshness on the bus makes it easier for a cheap and temporary interposer to convert local privileges and physical access into full access to enclaves. While actual mitigation will involve new hardware design, operators and customers can and must adjust configuration, physical controls and development practices to reduce exposure.