- What: Researchers at KU Leuven, ETH Zurich, Durham University, and Google disclosed DDRop, a DDR5 interposer that drops memory writes so the processor keeps reading stale encrypted data as if it were current.
Researchers have broken the memory integrity guarantees of Intel TDX, Intel Scalable SGX, and AMD SEV-SNP with a circuit board that costs under $200 to build. The attack, called DDRop, was disclosed on September 14, 2026 by a team from KU Leuven, ETH Zurich, Durham University, and Google. It does not crack the encryption engine or extract a key. It makes memory writes disappear, and the processor never finds out.
On an up to date Intel TDX host, that was enough to read a victim virtual machine's private memory, flip that machine into debug mode, copy it out in plaintext, restore the original contents so the victim showed no sign of tampering, and forge the launch measurement a confidential VM presents to a remote customer as proof it booted in a trusted state.
The freshness gap
Confidential computing keeps server memory encrypted so that anyone with physical access, including the cloud provider, sees only scrambled data. To cover the hundreds of gigabytes a modern server carries, these designs give up a property called freshness. The processor can confirm that a memory line is encrypted. It cannot confirm that the line holds the most recent value written to that address, and stale ciphertext still decrypts cleanly.
DDRop turns that tradeoff into an attack. The interposer is a small board of switches that sits on the DDR5 bus between the processor and a memory module and runs at full bus speed. To kill a write, it forces an error on the command bus, then cuts the wire the module uses to report that error. The module silently discards the command, the processor is never told, the old value stays put, and it reads back as current.
Why DDR5 was supposed to be out of reach
Earlier DDR5 interposer work, including TEE.fail, was passive. It listened to the memory bus and had to slow the bus down to keep second hand lab equipment in sync. Active attacks that changed what the memory saw, such as Battering RAM, only worked on older DDR4, because DDR5's redesigned command format defeats the address swapping trick they relied on. DDRop is the first active interposer attack to work at DDR5 speeds, and the first to break the integrity of a current Intel TDX system rather than only read data from it. The team is releasing board designs, controller firmware, and attack code on GitHub alongside the paper, which is due at ACM CCS 2026 in November.
From dropped writes to full guest control
TDX keeps each guest's page tables encrypted and under the control of trusted firmware. When that firmware writes empty entries to set up a new page table, DDRop drops those writes, so the table instead retains attacker chosen data planted in that memory beforehand. The attacker's own virtual machine can then map its address space onto any physical address and read or modify protected memory. With that primitive the researchers pulled a victim's private memory, switched the victim into debug mode for a plaintext dump, and rolled the memory back afterward.
Reading another guest's memory and toggling debug mode were demonstrated only under logical integrity, which is TDX's default. Cryptographic integrity, the optional stronger mode, would block both, because each involves changing data owned by a different VM. The researchers' test platform did not support that mode, so the boundary is argued rather than measured.
Attestation is the finding that scales
The attestation forgery is what architects should sit with. The researchers overwrote the launch measurement a VM uses to prove its state to a remote relying party. Because that write lands inside the attacker's own VM and under its own key, the hardware still marks the data valid. The team argues this survives cryptographic integrity as well, since that mode adds no freshness check and cannot tell reused contents from fresh ones. They could not confirm it on their hardware. If it holds, a machine the attacker controls can pass as a trusted one, and every secret release gated on that measurement is gated on nothing.
On AMD SEV-SNP the result is 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 attacks are specific to Intel TDX. All three technologies encrypt memory without the freshness check DDRop exploits, so all three are in scope.
What is not affected
- Intel Client SGX, used in some desktop and laptop chips, is not affected: it uses a hardware integrity tree that catches stale data. Intel has since retired it.
- NVIDIA confidential computing GPUs are not affected, because their memory sits inside the chip package where an interposer cannot be fitted.
- Arm CCA was not tested, and the researchers say it may be affected too.
- Home computers and phones are not the target. The attack is aimed at cloud and colocation servers running TDX, Scalable SGX, or SEV-SNP.
No patch, and what to do about it
There is nothing to install. The weakness is in the hardware design, and closing it for good needs new memory encryption silicon that provides integrity and freshness together. Software can raise the cost without removing the root cause: restrict the memory management features DDRop abuses, verify that important writes actually landed, and stop treating an attestation quote as proof on its own.
The threat model is specific. DDRop needs an attacker who already controls the host software stack and can get hands on the machine long enough to seat a board between the processor and a DIMM. The researchers told The Hacker News they have no evidence of DDRop or any comparable active interposer being used outside a laboratory, and no cloud service has been shown to be compromised. What changed on September 14 is that the physical tamper assumption underneath AWS, Azure, and Google Cloud confidential computing now has a $200 counterexample with public board files.
If your confidential VMs run in a hyperscaler region, physical access is the provider's problem and their datacenter controls apply. If you run TDX or SEV-SNP in colocation, at the edge, or on hardware a third party services, an operator with a badge and ten minutes is now inside the threat model, and your attestation quotes are the first thing to stop trusting blind.
grep -o -m1 sev_snp /proc/cpuinfo
cat /sys/module/kvm_amd/parameters/sev_snp
cat /sys/module/kvm_intel/parameters/tdx
sudo dmesg | grep -iE 'tdx|sev-snp|memory encryption'
cat /sys/devices/system/edac/mc/mc*/ce_countFix It Yourself
Everything above is what happened. This is what to run. The check commands change nothing.
Check whether you are exposed
Lists every GCP instance running Confidential Computing and which TEE it uses
gcloud compute instances list --filter="confidentialInstanceConfig.enableConfidentialCompute=true" --format="table(name,zone,confidentialInstanceConfig.confidentialInstanceType)"Lists every EC2 instance launched with AMD SEV-SNP enabled
aws ec2 describe-instances --query "Reservations[].Instances[?CpuOptions.AmdSevSnp=='enabled'].[InstanceId,InstanceType,Placement.AvailabilityZone]" --output tableOn a Linux host or guest, shows whether TDX or SEV-SNP is active and whether the memory controller is logging correctable errors, which a board forcing command bus errors would raise
cat /sys/module/kvm_intel/parameters/tdx /sys/module/kvm_amd/parameters/sev_snp 2>/dev/null; sudo dmesg | grep -iE 'tdx|sev-snp|memory encryption' | head -20; cat /sys/devices/system/edac/mc/mc*/ce_count 2>/dev/nullClose it
No vendor fix exists, so reduce what is in guest memory: put key material in an HSM backed vault where a dropped write cannot expose it
az keyvault create --name redeye-cvm-kv --resource-group rg-confidential --sku premium --enable-purge-protection trueRotate any secret that was resident in a confidential VM on hardware you do not physically control, disabling the old version rather than destroying it
gcloud secrets versions add prod-db-password --data-file=./new-secret.txt && gcloud secrets versions disable 1 --secret=prod-db-passwordContainment only, since there is no patch: record and ship memory controller error events so an interposer forcing bus errors leaves a trail
sudo apt-get install -y rasdaemon && sudo systemctl enable --now rasdaemon && sudo ras-mc-ctl --errorsPrompts for the agent you already run
You need an inventory of every confidential VM you run and where its attestation is actually verified
You want to know if any secret release path trusts an attestation quote without pinning the measurement
What to alert on
You cannot see the dropped write itself, the processor is never told, so alert on the two side effects instead. First, memory controller noise: watch the EDAC counters at /sys/devices/system/edac/mc/mc*/ce_count and the ras:mc_event tracepoint that rasdaemon writes, and raise an alert when correctable or command bus error counts climb on one channel or one DIMM slot with no matching temperature, age or workload change, because the interposer works by forcing errors on the command bus. Second, and more useful for most teams, the attestation verifier log: alert whenever the MRTD or RTMR values in a TDX quote, or the MEASUREMENT and POLICY fields in a SEV-SNP report, change for a workload whose image digest did not change, and alert on any report where the TDX ATTRIBUTES debug bit or the SEV-SNP policy DEBUG bit is set. On Azure those are the MAA token claims x-ms-sevsnpvm-launchmeasurement and x-ms-sevsnpvm-is-debuggable under x-ms-isolation-tee. Pair both with chassis intrusion from your BMC, the Redfish Chassis Status resource and the IPMI Physical Security sensor in SEL events, since seating the board means opening the server.
Questions about your exposure?
RedEye Security provides assessments for organizations that need to understand their real risk.
Talk to us