DDRop: A Tiny Circuit Bolted to a Server Can Fool Intel and AMD's Most Secure Modes
Researchers show how a small piece of hardware, paired with attacker software already on the machine, tricks confidential computing into reading stale data as if it were fresh.

Key points
- Researchers have disclosed DDRop, a hardware attack that defeats confidential computing on Intel TDX and AMD SEV-SNP servers.
- The attack silently drops memory writes so the processor keeps reading old encrypted data instead of the new value.
- An attacker needs software control of the server plus brief physical access to fit a small circuit onto the memory path.
- The technique undermines the core promise cloud vendors make about protecting customer data even from a rogue host.
- No affected chip vendor has shipped a fix at time of writing; the practical defence is physical inspection and tighter data-centre access.
A new attack called DDRop breaks one of the strongest privacy features sold with modern server chips, and it does so with a circuit small enough to install during a maintenance window.
The research, covered by The Hacker News, targets confidential computing, the feature Intel and AMD market to cloud customers as a way to run sensitive workloads on someone else's server without the server's owner being able to peek at the data. Intel's version is called TDX. AMD's is called SEV-SNP. Both encrypt a customer's memory so that even the machine's operator, in theory, cannot read it.
DDRop pokes a hole in that promise.
What does the attack actually do?
It makes the server's memory quietly lie. When the processor tries to write a new value into memory, the attacker's added circuit swallows the write. The processor assumes the update landed, so the next time it reads that address it gets the old encrypted value back, and the encryption layer has no way of knowing anything went wrong.
That sounds abstract, but in practice it means an attacker can freeze parts of a program in time. A password check that should now say "denied" keeps saying "allowed". A counter that should have moved on stays put. A security patch loaded into memory never really takes effect.
Confidential computing was designed to catch tampering with the contents of memory, not tampering with whether a write happened at all. That's the gap DDRop walks through.
Who can actually pull this off?
Not a random person on the internet. The attacker needs two things simultaneously: software control of the machine, meaning they're already running code as the host operator or have broken in that far, and brief physical access to install a small circuit on the memory path. That's a serious bar. It's also exactly the threat model confidential computing was sold to defend against, because the whole point is that a malicious or compromised cloud provider still shouldn't be able to see or alter a customer's data.
We've followed the hardware side of this problem before. Our 25 August story on chip giants racing to build quantum-proof encryption into silicon noted that hardware-level trust assumptions are fragile in ways firmware patches rarely fix.
The people who should care are cloud customers running regulated or high-value workloads including banks, health data processors and government agencies, along with the cloud providers who told them TDX and SEV-SNP made those workloads safe.
What does this mean for ordinary customers?
For a nurse using a hospital app or a shopper buying online, nothing changes today. This isn't a mass exploit. There's no phishing email, no update to install, no password to change. The attack needs someone physically at a specific server with the skills to modify it.
The wider point is about trust in cloud marketing. If your bank or hospital told a regulator that confidential computing meant customer data was safe even from insiders, that claim now has a caveat with a soldering iron attached to it.
Where does this leave Intel and AMD?
Awkwardly. The encryption is doing what it was designed to do. Neither TDX nor SEV-SNP verifies that a write to memory actually stuck, and fixing that in silicon isn't a firmware update job. Expect vendor advisories, guidance on physical security controls for host machines, and detection work looking for unexpected hardware on the DIMM path.
Confidential computing shifted the threat model, but the industry never fully priced in the hardware-implant scenario the model practically invites.
If you bought confidential computing to satisfy a compliance requirement, ask your provider how they physically inspect and seal the servers running it.


