Here is a blog-ready comment in the larger-paragraph style. The crucial point is that **DDRop does not represent a remote attack against Intel TDX or AMD SEV-SNP, nor is there evidence that cloud providers have been compromised using it**. It is a hardware attack requiring both control of the host software and a brief opportunity to physically install an interposer on the DDR5 memory bus. But that caveat should not make the research easy to dismiss, because confidential computing exists specifically to protect workloads even when the cloud operator, hypervisor, or infrastructure administrator is not trusted. DDRop shows that once physical memory manipulation is added to that threat model, the absence of a cryptographic freshness guarantee can undermine some of the strongest assumptions behind current confidential-computing architectures. ([The Hacker News][1])

## DDRop Shows That Encrypting Memory Is Not the Same as Proving Memory Is Fresh

DDRop is a newly disclosed hardware attack against Intel TDX, Intel Scalable SGX, and AMD SEV-SNP that exploits a subtle but fundamental limitation in the way modern confidential-computing systems protect large amounts of server memory. These technologies encrypt memory so that an untrusted hypervisor or someone observing the memory bus cannot simply read a confidential virtual machine’s plaintext data. What they generally do not provide across scalable server memory, however, is a cryptographic freshness guarantee capable of proving that the encrypted value returned from DRAM is the most recently written value. DDRop exploits precisely this distinction. Researchers from KU Leuven, ETH Zurich, Durham University, and Google built a low-cost DDR5 interposer that can selectively make memory writes disappear. The processor believes the write occurred, but the memory module silently retains the previous ciphertext, which remains cryptographically valid when it is later read. The result is a replay primitive in which stale encrypted data is accepted as current data. ([DDRop][2])

The attack is particularly interesting because it does not need to decrypt memory on the wire. DDRop instead interferes with the correctness of memory updates. The researchers built an interposer costing approximately $159 in components that sits between the processor and a DDR5 RDIMM and operates at native DDR5 speed. To suppress a write, the device deliberately creates a parity error on the DDR5 command bus and simultaneously prevents the error indication from reaching the processor. The DRAM module rejects the command, while the processor remains unaware that the requested write never happened. The previously stored encrypted value therefore survives. Memory encryption behaves exactly as designed when that value is later fetched: it decrypts successfully because the ciphertext itself has not been corrupted. The missing property is not encryption but freshness. ([DDRop][2])

That difference between confidentiality, integrity, and freshness is the core technical lesson from DDRop. Encryption answers whether someone who observes stored data can understand it. Integrity determines whether data has been modified improperly. Freshness determines whether the data being presented is the latest legitimate version rather than an older valid version being replayed. A system can therefore protect confidentiality and even provide some integrity checks while remaining vulnerable to stale-data replay. This is why simply saying “memory is encrypted” does not fully describe the security guarantee provided by a confidential-computing platform. For remote attestation and protected virtual machines, the age and sequence of data can matter just as much as whether the data has been altered. ([DDRop][2])

On Intel TDX, the researchers were able to turn this write-dropping capability into a particularly powerful primitive by targeting Secure Extended Page Tables, or SEPT. TDX uses these protected page tables to control how confidential virtual-machine memory maps onto physical memory, with initialization performed by trusted TDX firmware rather than the untrusted hypervisor. When the TDX module allocates a new SEPT page, it initializes entries before allowing the page to become active. DDRop can selectively discard those initialization writes, leaving previously prepared ciphertext in the physical page. The researchers show that this stale ciphertext can be chosen so that, when decrypted in the attacker-controlled Trust Domain, it becomes malicious page-table entries. This gives the attacker-controlled confidential VM the ability to remap its own addresses onto arbitrary physical memory locations. ([DDRop][2])

Under Intel TDX’s default logical-integrity mode, this primitive allowed the researchers to interfere with data belonging to other Trust Domains. They demonstrated that an attacker could modify a victim VM’s protected control information sufficiently to activate its debug mode. Once debug mode was enabled, the hostile hypervisor could use the legitimate TDX debug interface to extract the victim’s memory in plaintext. The researchers then restored the original ciphertext, allowing the victim VM to continue running without an obvious persistent change to its attestation state. This is significant because the entire purpose of a confidential VM is to remain protected even if the host hypervisor itself is malicious. DDRop provides a way for a malicious infrastructure operator with physical access to undermine that boundary. ([The Hacker News][1])

Intel’s stronger optional cryptographic-integrity mode changes part of this picture. The researchers acknowledge that some of their cross-VM attacks, including directly reading victim memory and toggling another Trust Domain’s debug state, would be blocked by cryptographic integrity because those operations involve manipulating information protected under a different encryption key domain. This is an important limitation and should be preserved when discussing the research. DDRop does not identically defeat every possible TDX configuration. However, the researchers argue that attestation forgery remains possible even with cryptographic integrity enabled because the attacker manipulates stale information inside a Trust Domain they themselves control, where the relevant data remains valid under the attacker VM’s own key. Their test platform did not support the stronger mode, so they could not experimentally demonstrate that particular claim under cryptographic-integrity mode. ([The Hacker News][1])

The attestation result may ultimately be the most important finding. Remote attestation is supposed to allow a customer to verify cryptographically that a confidential VM started from the expected trusted software measurement before releasing secrets or workloads to it. The researchers demonstrated that DDRop can manipulate the launch measurement of an attacker-controlled TDX VM so that a malicious or backdoored workload can produce an attestation report containing the measurement expected from a legitimate VM. In other words, the attack does not merely expose encrypted memory. Under the demonstrated conditions, it can interfere with the evidence used to decide whether the protected environment itself should be trusted. ([DDRop][2])

That distinction elevates DDRop from an interesting memory-bus attack into a challenge to the confidential-computing trust model. Many confidential workloads are designed around the assumption that a remote customer does not need to trust the cloud administrator because the hardware attestation mechanism independently proves what is executing. If an adversary with infrastructure access can manipulate the state feeding into that attestation while still obtaining a valid hardware-signed report, the customer may release cryptographic keys or sensitive data to an environment that is not actually running the expected software. The ultimate failure is therefore not simply confidentiality or integrity but potentially the root of trust used to bootstrap both.

The demonstrated AMD SEV-SNP impact is narrower. The researchers used dropped writes in conjunction with AMD’s page-relocation mechanism to copy plaintext content from one protected page into another. They did not reproduce the TDX-specific debug-mode or attestation-forgery attacks against SEV-SNP. AMD’s September 14 advisory acknowledges the research but states that the attack requires privileged software access plus physical access to the motherboard and therefore falls outside the published SEV-SNP threat model. AMD says it does not plan to assign a CVE or release mitigations specifically in response to DDRop. The bulletin lists several EPYC 4004, 4005, 8004, 9004 and 9005 families, along with MI300A, in the affected-product context. ([AMD][3])

Intel has taken a broadly similar position toward physical interposer attacks, treating them as outside the intended protection boundary of current server memory-encryption technology. The Hacker News reports that Intel does not plan to assign a CVE specifically for this class of physical attack and has previously characterized physical interposer research as “out of scope, but not out of mind.” Intel’s position is understandable from a formal threat-model perspective: product security guarantees always require defined attacker capabilities, and no system protects against an unlimited physical adversary. But DDRop raises a legitimate architectural question because one of the principal selling points of confidential computing is precisely that customers do not need to trust the system operator with their plaintext workload. ([The Hacker News][1])

This is where the practical threat model becomes more nuanced than simply saying “physical access required.” The researchers assume the attacker can control the host software, hypervisor, and BIOS, which already fits the kind of hostile infrastructure environment confidential computing is intended to tolerate. What DDRop adds is a one-time physical installation of a small interposer that can reportedly be fitted within minutes. After installation, control of the attack is software-driven. The researchers identify rogue data-center technicians, compromised contractors, supply-chain tampering, or compelled physical access as examples of how such a device might be introduced. ([DDRop][2])

For a normal enterprise server locked inside the organization’s own data center, those conditions may make DDRop a low-probability threat compared with ransomware, stolen credentials, remote vulnerabilities, or ordinary administrative compromise. For workloads specifically moved into confidential computing because the customer does not want to trust the cloud operator, however, the distinction is much more important. A technology designed to withstand a malicious hypervisor naturally invites scrutiny of the remaining layers that the infrastructure operator can physically influence. The research therefore does not prove that public clouds are suddenly unsafe, but it does show that hardware possession still matters even when memory encryption and remote attestation are deployed.

It is also important to emphasize that there is **no evidence DDRop has been used outside the laboratory**, and the researchers explicitly told The Hacker News that they have not observed this attack or a comparable active DDR5 interposer being used in real-world operations. The research also does not demonstrate that AWS, Microsoft Azure, Google Cloud, or another confidential-computing provider has been breached using DDRop. Any headline suggesting that DDRop remotely “breaks Azure” or “breaks AWS confidential VMs” would therefore substantially overstate the findings. ([The Hacker News][1])

The attack is nevertheless important because it makes sophisticated hardware tampering dramatically more accessible. Earlier memory-bus attacks sometimes depended on extremely expensive analyzers or modifications that slowed memory enough to be operationally noticeable. The DDRop team says its interposer costs less than $200, operates at native DDR5 speed, and can be installed quickly. The shift from six-figure laboratory equipment to a small commodity-component board changes assumptions about which adversaries may realistically possess the capability. ([DDRop][2])

This follows a broader trend in hardware security where physical attacks once assumed to belong to specialized laboratories gradually become cheaper and more repeatable. The researchers contrast DDRop with earlier techniques such as WireTap, TEE.fail, BadRAM, and Battering RAM. TEE.fail demonstrated passive observation of DDR5 traffic but required memory downclocking and did not actively alter commands. Battering RAM provided low-cost active manipulation on DDR4 through address aliasing, but DDR5’s redesigned command architecture made that specific technique impractical. DDRop takes a different route by suppressing writes rather than rewriting memory addresses, making active interposition feasible again on current DDR5 server platforms. ([DDRop][2])

From a defensive perspective, there is no simple software patch that permanently eliminates the underlying weakness because the root issue is architectural. The researchers argue that strong protection ultimately requires cryptographic memory integrity combined with freshness or replay protection. That can involve maintaining authenticated metadata or version counters so the processor can determine not merely that ciphertext is valid but that it is the current ciphertext expected for that memory location. The difficulty, naturally, is that maintaining this metadata for hundreds of gigabytes or terabytes of high-speed server memory introduces performance, complexity, and storage costs. Confidential computing is once again demonstrating the irritating habit of physics and performance engineering refusing to obey cybersecurity PowerPoint slides. ([DDRop][2])

Software and firmware changes can still make exploitation harder. The DDRop researchers discuss limiting or redesigning memory-management APIs that provide particularly useful primitives, verifying that security-critical memory writes actually reached DRAM, and detecting interposers through boot-time or timing-based checks. These approaches can remove individual exploit paths or increase attacker difficulty, but they do not provide the cryptographic freshness guarantee absent from the underlying memory architecture. ([DDRop][2])

For cloud and data-center operators, physical chain-of-custody controls therefore become part of the confidential-computing architecture rather than an unrelated facilities-management issue. Servers supporting high-assurance confidential workloads should have strong rack-access controls, tamper-evident hardware practices, asset inspection, supply-chain verification, and restricted technician access. Hardware changes involving DIMMs or system boards should be recorded and verified, and high-security environments may increasingly need mechanisms capable of detecting unauthorized devices inserted on memory interfaces.

Remote customers using confidential computing should similarly avoid assuming that hardware attestation reduces every trust question to a binary cryptographic answer. Attestation proves whatever the underlying hardware root of trust can reliably measure and sign. If the hardware architecture contains assumptions about physical memory that fall outside the attestation mechanism, those assumptions remain part of the customer’s actual threat model even if they are invisible in the attestation report.

This has particular implications for highly sensitive AI, financial, healthcare, defence, cryptographic, and multi-party computation workloads increasingly being promoted for confidential cloud deployment. Organizations adopting these services should understand whether they are primarily trying to protect against other tenants, a compromised host OS, malicious cloud administrators, physical insiders, supply-chain tampering, or nation-state access to infrastructure. Different confidential-computing platforms provide strong protection against many of these threats, but no deployment should casually assume that “confidential VM” means the entire physical system can be treated as hostile without qualification.

DDRop therefore should not be interpreted as proof that Intel TDX or AMD SEV-SNP are useless. That would discard substantial protection because one layer does not solve every conceivable physical attack. TDX and SEV-SNP still raise the difficulty of obtaining plaintext dramatically compared with ordinary virtualization and can prevent a compromised hypervisor from simply inspecting guest memory using normal software mechanisms. AMD’s argument that the demonstrated physical attack lies outside its published SEV-SNP threat model is technically important and accurate as a statement about the defined boundary. ([AMD][3])

But the research does expose an uncomfortable gap between formal threat models and how confidential computing is sometimes understood commercially. Customers may hear that their workload remains confidential even from the cloud provider and reasonably interpret that as meaning the provider cannot manipulate the infrastructure to defeat the protection. DDRop demonstrates that this statement needs qualification when the infrastructure operator, supply chain, or physical insider can tamper with the memory bus itself.

The larger architectural lesson is that encryption alone does not create trusted memory. Confidential computing increasingly depends on multiple properties working together: confidentiality, integrity, freshness, isolation, secure initialization, and reliable attestation. Remove freshness, and an attacker may not need to discover the encryption key at all. They can instead persuade the processor to reuse an older encrypted reality.

That is what makes DDRop so interesting.

The researchers never break AES.

They do not extract the memory-encryption key.

They do not remotely exploit the confidential VM.

They simply prevent selected writes from reaching DRAM and allow the processor to decrypt yesterday’s valid ciphertext as though it were today’s state.

For confidential computing, that is a powerful reminder that protecting data in use means more than encrypting what leaves the CPU. The system must also be able to prove that the data returning to the CPU is not only authentic, but current. ([DDRop][2])

A suitable title is: **“DDRop Exposes the Missing Freshness Guarantee in Intel TDX and AMD SEV-SNP Confidential Computing.”**

The most important caveat for publication is that **DDRop requires privileged host control plus physical access to install a DDR5 interposer, and there is currently no evidence of real-world exploitation or compromise of public-cloud confidential-computing services**. The research is significant because it demonstrates, using hardware costing about **$159**, that active DDR5 memory manipulation can undermine TDX and SEV-SNP assumptions and, on TDX, can even be used to demonstrate debug-mode manipulation and attestation forgery. AMD considers the technique outside the SEV-SNP threat model and is not assigning a CVE or mitigation specifically for it. ([DDRop][2])

[1]: https://thehackernews.com/2026/09/new-ddrop-attack-breaks-intel-tdx-and.html "New DDRop Attack Breaks Intel TDX and AMD SEV-SNP Confidential Computing"
[2]: https://ddropattack.eu/ "DDRop"
[3]: https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3048.html "Physical Memory Fault Injection Attacks on DDR5"

Researchers have disclosed a new hardware attack, called DDRop, that breaks the memory protection in Intel and AMD confidential computing by silently dropping writes to a server's memory, so the processor keeps reading old encrypted data as if it were current. The attack requires an attacker who already controls the server's software and can briefly access the machine to insert a small circuit

Source: New DDRop Attack Breaks Intel TDX and AMD SEV-SNP Confidential Computing via The Hacker News — published 14 Sep 2026.