Researchers have disclosed a new hardware attack, named **DDRop**, that successfully breaks the memory protection in **Intel** and **AMD** confidential computing environments. The attack works by silently dropping write operations to a server's memory, causing the processor to repeatedly read old encrypted data, mistaking it for the most current information. ### The Mechanics of DDRop The **DDRop** attack necessitates an attacker who already controls the server's software and can gain brief physical access to the machine. During this access, a small circuit board, known as an **interposer**, is inserted between the processor and a memory module. This interposer costs less than $200 to build and is capable of operating at full **DDR5** speed.  Confidential computing encrypts a server's memory to ensure data privacy, even from the cloud provider. However, to handle the vast amounts of memory in cloud servers, these designs often forgo a 'freshness' guarantee. While the processor can verify that memory is encrypted, it cannot confirm that it holds the absolute latest written value, allowing old encrypted data to decrypt correctly. **DDRop** exploits this gap. When the interposer drops a write, the previous value remains in memory. The processor then reads this older data, believing the update occurred, without the encryption engine detecting any anomaly. This marks the first active interposer attack to function on **DDR5** memory in modern cloud servers. It's also the first to compromise the integrity of an up-to-date **Intel TDX** system, rather than merely reading data. Previous **DDR5** interposer attacks, such as **TEE.fail**, were passive, only listening to the memory bus. Active attacks that modified memory, like **Battering RAM**, were limited to older **DDR4** systems. **DDRop** circumvents **DDR5**'s redesigned command format by strategically dropping writes instead of swapping addresses. To achieve this, the interposer forces an error on the command bus and then severs the wire the memory module uses to report errors. This causes the module to silently discard the command, and the processor remains unaware of the dropped write. ### Impact on Intel TDX and AMD SEV-SNP **DDRop** is the culmination of research by teams at **KU Leuven**, **ETH Zurich**, **Durham University**, and **Google**. The findings are slated for presentation at the **ACM CCS 2026** conference in November. The researchers have made the interposer's board designs, controller firmware, and attack code publicly available on **GitHub**, alongside their research paper. On **Intel TDX**, the researchers leveraged write-dropping to gain full control over a protected virtual machine. **TDX** encrypts each virtual machine's page tables, placing them under the control of trusted firmware. By dropping writes when this firmware attempts to create empty entries for a new page table, **DDRop** allows the table to retain attacker-chosen data pre-existing in that memory. This enables an attacker's virtual machine to map its memory onto any physical address, facilitating reading or altering protected memory.  With this access, they successfully read a victim virtual machine's private memory and switched a victim machine into debug mode. This allowed them to copy its memory in plaintext, then restore the original data, leaving no trace of tampering. Furthermore, they could overwrite the launch measurement a virtual machine uses to attest to a remote customer that it started in a known, trusted state. This allowed an attacker-controlled virtual machine to pass this check as if it were a legitimate, trusted instance. Some of these findings, such as reading victim memory and toggling debug mode, were demonstrated under **TDX**'s default 'logical integrity' mode. The researchers note that **TDX**'s optional, stronger 'cryptographic integrity' mode would likely block these specific actions, as they involve altering data belonging to another virtual machine. However, they argue that forging a machine's own attestation would still be possible under the stronger mode, as the write occurs within the attacker's own virtual machine and under its own key, which the hardware would deem valid. Cryptographic integrity also lacks a freshness check. On **AMD SEV-SNP**, the attack's scope is narrower. Dropping writes during **AMD**'s page-relocation feature allowed researchers to copy the contents of one victim page into another. However, the debug-mode and attestation-forgery attacks are specific to **Intel TDX**. All three technologies – **Intel TDX**, **Intel Scalable SGX**, and **AMD SEV-SNP** – encrypt memory without the crucial freshness check that **DDRop** exploits, making them vulnerable. **Intel**'s older **Client SGX**, used in some desktop and laptop chips, is not affected due to its hardware integrity tree that detects stale data, although this technology has been retired. **NVIDIA**'s confidential-computing GPUs are immune to this attack because their memory is integrated within the chip package, preventing interposer installation. The researchers did not test **Arm**'s **CCA** but suggest it may also be affected. The attack specifically targets cloud servers, not consumer devices. **Intel TDX**, **Scalable SGX**, and **AMD SEV-SNP** are offered by major cloud platforms, including **AWS**, **Microsoft Azure**, and **Google Cloud**, to safeguard customer workloads. While **DDRop** demonstrates a significant vulnerability, there is no evidence of it being used outside a laboratory setting. ### The Challenge of Remediation There is no simple software patch for **DDRop**. The vulnerability lies in the fundamental hardware design, as current scalable memory encryption sacrifices freshness checks for the ability to protect large memory capacities. A permanent solution would require new memory-encryption hardware incorporating both integrity and freshness checks. Software-based mitigations could raise the bar for attackers, such as restricting memory-management features abused by **DDRop**, verifying that critical writes are successfully completed, and implementing interposer detection during boot processes. **Intel** and **AMD** were informed of **DDRop** through coordinated disclosure. Both companies acknowledged the findings and committed to issuing security bulletins. However, neither provided specific mitigation guidance or a timeline for a fix, according to the researchers. **AMD** stated that because the attack requires physical access, it "falls outside the scope of the published threat model for **SEV / SNP**." **Intel** holds a similar stance regarding physical attacks against server memory. **Intel** has previously indicated that physical interposer attacks of this nature are outside the protection offered by its memory encryption and does not plan to assign a **CVE** to such attacks. While describing this research area as "out of scope, but not out of mind," **Intel**'s optional cryptographic-integrity mode, available on some current **Xeon** processors, already blocks parts of **DDRop**. **Intel** is also reportedly developing stronger memory-encryption designs for future chips, including a proposal called cache-line versioning, which would add a freshness check to the memory bus. However, its efficacy against **DDRop** remains unconfirmed by **Intel**. **AMD**'s bulletin on **DDRop** is expected to be published on its product security page. **Intel** did not provide further comment prior to publication. The low cost of building the interposer, estimated at about $159 for parts (excluding development and labor), combined with its quick installation and software-driven operation, underscores the seriousness of this hardware vulnerability.