University of Toronto researchers have shown that non-uniform Rowhammer patterns defeat NVIDIA’s sideband ECC on GDDR6 workstation GPUs, yielding a root shell on the host in under two minutes. Three of the four affected cards were tested on rented cloud GPUs. The coverage is getting two important things wrong, and both of them make the problem sound broader than it is.
What happened
GPUThor — “Amplifying Rowhammer Attacks via Non-Uniform Patterns to Exploit ECC-Protected GPUs” — has been accepted to ACM CCS 2026, one of the field’s top peer-reviewed venues. The authors are Chris S. Lin, Joyce Qu, Aditya Rajeev, and Gururaj Saileshwar, the same group behind GPUHammer in 2025.
Four Ampere-class workstation GPUs with GDDR6 memory are affected: the RTX A4000, A4500, A5000, and A6000. The bit-flip rates are the headline finding, because they are enormous compared with prior work — 377,552 flips per gigabyte on the A5000, 114,488 on the A6000, 75,024 on the A4500, and 72,768 on the A4000. The paper claims between 500 and 23,500 times more flips than earlier GPU Rowhammer research.
What gets defeated is sideband SECDED ECC, specifically. NVIDIA’s scheme protects 16 bytes of data with 1 byte of ECC, or 2 bytes of sideband ECC per 32 bytes of data. Single-error correction, double-error detection. The attack works by inducing multiple bit errors inside a single ECC chunk: the researchers produced 387 double-bit errors, which ECC detects but cannot correct, and 2 triple-bit errors, which pass silently as corrupted data.
From there, corrupting GPU page tables yields arbitrary read and write access to CPU memory and a root shell on the host in 0.7 to 1.2 minutes. There is also a denial-of-service mode: roughly one uncorrectable error every two hours on an ECC-enabled A6000, costing about 13% of daily GPU availability and causing the card to flag itself as defective within a day. Exhausting the row-remapping budget also opens the door to RMA abuse.
The threat model is shared GPU tenancy. The attacker is an unprivileged user who can launch CUDA kernels and, in the paper’s words, “co-locate with another victim user on a time-shared GPU in the cloud.” Three of the four cards were tested on rented cloud GPUs, which is what makes this a procurement question rather than a lab curiosity.
Disclosure was coordinated: reported to NVIDIA on 29 April 2026, embargoed to 25 August, with a security notice published by NVIDIA. Code and artifacts are withheld until 15 November 2026.
Two corrections to today’s coverage
A100-class hardware is not in scope. This is the important one. The researchers explicitly tested HBM, GDDR6X, and newer-generation GDDR6, and observed no bit flips on any of them, which they attribute to different target row refresh implementations. Reporting that places datacenter accelerators inside the blast radius contradicts the paper it is describing. Four Ampere workstation cards flipped. The AI training fleet, as tested, did not.
The model-accuracy result belongs to a different paper. Coverage attaching machine learning accuracy degradation to GPUThor is reaching back to the same group’s 2025 GPUHammer work, which did degrade model accuracy. GPUThor contains no ML accuracy experiments at all. It demonstrates denial of service and privilege escalation. Those are serious enough without borrowing a finding from elsewhere.
Both errors push in the same direction — toward “Rowhammer breaks AI datacenters” — and both make the actual finding harder to act on, because they point defenders at the wrong hardware.
Why it matters
The value here is not that a novel memory attack exists. It is that the economics of GPU rental have quietly recreated a threat model the industry spent a decade engineering out of shared CPU infrastructure.
Workstation-class Ampere cards are exactly what the second tier of GPU rental markets is full of. They are what you get when you rent by the hour from a provider that is not a hyperscaler, and they are what sits in university clusters, render farms, and internal shared-compute pools. In all of those, “another tenant can run a CUDA kernel next to yours” is not a hypothetical, it is the product.
ECC is the reason those environments are considered safe to share. The finding here is that a specific, widely deployed ECC implementation does not survive contact with a patterned attack, and that the failure mode includes silent corruption — the two triple-bit errors that ECC neither corrected nor flagged. Silent corruption in a shared numerical workload is a category of problem most teams have no detection for at all.
The denial-of-service angle deserves attention on its own. A card that flags itself defective within a day of sustained attack is a supply chain problem as much as a security one: it looks like hardware failure, it triggers an RMA, and it does not look like an attack to anyone in the loop.
What to do
- If you rent GPU capacity, ask specifically about tenancy isolation on Ampere workstation SKUs. Not about the provider’s datacenter fleet, which is not what was broken. The question is whether A4000/A4500/A5000/A6000 capacity is time-shared between tenants, and what sits between them.
- Enable SYS-ECC and IOMMU/DMA isolation where you control the host.
- Start collecting GPU ECC error counters. A rise in correctable errors is the early signal, and most shops are not looking at this telemetry at all. It is also how you distinguish an attack from a genuinely failing card before you ship it back.
- Treat sustained uncorrectable errors on shared GPUs as a security event, not solely a hardware fault, until you can rule out the alternative.
- Note the 15 November date. Artifacts become public then. Whatever isolation review this prompts should be finished before that, not started after it.
Sourcing note
This is the best-sourced item we have run: a peer-reviewed paper accepted to ACM CCS 2026, named researchers at a named institution, coordinated disclosure with a four-month embargo, and a vendor security notice on record. Bit-flip counts, affected models, timings, and the negative results on HBM and GDDR6X all come from the paper itself. NVIDIA’s security notice could not be retrieved directly — the host blocks automated fetching — so its exact wording, affected-product list, and severity rating are unverified at primary, and no CVE is mentioned in any primary source we could reach. There is a minor date conflict on when NVIDIA published: the paper and project page say 25 August, one outlet says 21 August. Exploit code is not public until 15 November 2026.