GPU Rowhammer 2026: 3 attacks reached root shell on NVIDIA GDDR6

Summary. On 6-7 April 2026, three independent teams disclosed GPU Rowhammer attacks that all reached the same place: corrupting GPU page tables from an unprivileged CUDA kernel. One of them, GPUBreach from the University of Toronto, went further and produced a root shell on the host CPU with the IOMMU enabled, the configuration NVIDIA, AMD and Microsoft all tell you to keep on. The researchers disclosed to NVIDIA on 11 November 2025; Google paid a $600 bounty; NVIDIA has assigned no CVEs and issued no new bulletin, pointing instead to its July 2025 Rowhammer notice. The measured exposure is narrower than the headline: the predecessor attack, GPUHammer, induced 1,171 bit flips on an RTX 3060 and 202 on an RTX A6000, while testing found zero flips on the RTX 3080, RTX 4060, RTX 4060 Ti, RTX 6000 Ada and RTX 5050. A100, H100 and H200 accelerators are assessed as likely resistant because HBM ships with on-die ECC on by default. GPUBreach gets its Black Hat USA 2026 Briefings slot on 5-6 August at Mandalay Bay. If you run Ampere-generation GDDR6 cards where more than one party can submit CUDA work, this is a config review, not a patch cycle: there is nothing to patch yet.

What was actually disclosed, and when

Rowhammer is old. Yoongu Kim and colleagues at Carnegie Mellon published the first DRAM disturbance study in 2014, and CPU memory has since picked up Target Row Refresh, LPDDR5 Refresh Management and probabilistic adjacent-row activation. GPU memory picked up none of that.

GPUHammer, published at USENIX Security 2025 by the same Toronto group, closed the first gap: it showed GDDR6 in NVIDIA Ampere cards flips under hammering. What it did with the flips was blunt. Flip the exponent bit of a model weight and accuracy collapses; the team measured a drop from 80 per cent to 0.1 per cent on an ImageNet model, which Gururaj Saileshwar, assistant professor in the department of computer science at the University of Toronto, described to U of T News as "catastrophic brain damage" to the model.

GPUBreach answers the question GPUHammer left open. Instead of flipping data, it flips page table entries. The project page sets out the chain, and the Cloud Security Alliance's research note dates the coordinated disclosure to 6-7 April 2026, with the paper and GitHub artifact following around 13 April and the IEEE S&P 2026 presentation on 18-20 May 2026 in San Francisco.

Two concurrent papers landed at the same venue. GDDRHammer, from UNC Chapel Hill, Georgia Tech and MBZUAI, corrupts aperture bits in last-level page table entries to redirect GPU virtual addresses into CPU physical memory over PCIe BAR1. GeForge, from Purdue, Clemson, the University of Rochester and the University of Western Australia, forges new mappings by hammering the page directory instead. Both reach CPU memory. Neither reaches a root shell the way GPUBreach does with the IOMMU left on.

Capability	GPUBreach	GDDRHammer	GeForge
GPU page-table corruption via GDDR6 Rowhammer	Yes	Yes	Yes
Arbitrary GPU memory read and write	Yes	Yes	Yes
Reads or writes CPU memory	Yes	Yes (limited, via aperture bits)	Yes
Host root shell	Yes	No	Yes
Works with the IOMMU enabled	Yes	Not applicable	No, requires IOMMU disabled
Structure targeted	Last-level PTEs plus driver state	Last-level PTE aperture bits	Page directory (PD0)

Source: the GPUBreach project page comparison and the CSA research note, April 2026.

The four stages, and the one that matters

Stage one is placement. GPU page tables live in GPU memory. The Toronto team reverse-engineered the NVIDIA driver to find that page tables sit in contiguous 2 MB regions, and that once the first region fills, later regions come from the same pool as user data. That co-location is what makes the row sandwich possible. They then used CUDA's Unified Virtual Memory subsystem to grab 64 KB and 4 KB frames, and a timing side channel on UVM allocations to detect when a new page-table region appeared next to a known-flippable row.

Stage two is the flip. Hammer the neighbouring rows, corrupt a page frame number inside a PTE, point it at another page-table page, and the unprivileged CUDA process now controls its own page tables. That gives arbitrary read and write across GPU memory, including across processes under time-sliced sharing.

Stages three and four are the part that changes the threat model. The obvious next move is to DMA into host memory, and that is what the IOMMU exists to stop. GPUBreach does not fight the IOMMU. It writes into buffers the IOMMU already permits, because those buffers belong to the GPU driver itself. Corrupting driver state triggers memory-safety bugs in NVIDIA's kernel-mode driver, which runs in ring 0, and those bugs yield an arbitrary kernel write. A root shell follows.

The engineering lesson is uncomfortable and worth stating plainly: a boundary you enforce in hardware is only as good as the code sitting on the trusted side of it.

On the GPU side alone, the team also demonstrated key leakage from NVIDIA cuPQC while post-quantum keys sat in GPU DRAM, and a quieter model attack than weight flipping: tamper with a single branch in cuBLAS SASS resident in GPU memory and accuracy goes from 80 per cent to zero across the board.

Which cards are actually exposed

This is where most coverage stopped and where the operational answer lives. The researchers tested a spread of GDDR6, GDDR6X and GDDR7 parts, and the flip primitive did not reproduce everywhere.

GPU	Memory	Bit flips observed in testing	What it means for you
NVIDIA RTX A6000 (Ampere)	GDDR6	202 (GPUHammer)	Full GPUBreach chain demonstrated here
NVIDIA RTX 3060 (Ampere)	GDDR6	1,171 (GPUHammer)	Most flip-prone part measured
NVIDIA RTX 3080	GDDR6X	Zero	No reproduction reported
NVIDIA RTX 4060 and 4060 Ti (Ada)	GDDR6	Zero	No reproduction reported
NVIDIA RTX 6000 Ada	GDDR6	Zero	No reproduction reported
NVIDIA RTX 5050 (Blackwell)	GDDR7	Zero	GDDR7 adds on-die ECC
NVIDIA A100, H100, H200	HBM2e/HBM3/HBM3e	Not demonstrated	Assessed likely resistant; on-die ECC on by default

Source: CSA research note, 7 April 2026, summarising the researchers' own assessments.

Read the table twice before you write a risk memo. The cards that carry your training runs, the H100 and H200 class, are the ones the researchers assess as likely resistant. The cards that flip are Ampere-generation GDDR6, and the RTX A6000 in particular has been a common workstation and inference choice for five years. The CSA note is careful to add that these are results on specific cards, not architectural guarantees across the GDDR6 line, and we would treat "zero flips observed" as "not yet reproduced" rather than "safe".

There is a second-order point about accounting. Plenty of Indian and global GPU-as-a-service fleets are built on exactly the mid-tier GDDR6 parts, because that is what pencils out for inference. JarvisLabs advertises Indian capacity from ₹41.31 per hour and the RTX A6000 at ₹75 per hour; E2E Networks lists the L40S at ₹102 per hour. The economics that made those fleets attractive are the same economics that put Ampere-class GDDR6 under multi-user workloads.

The threat model: who can submit CUDA work?

GPUBreach needs one thing that is easy to overlook. It does not need physical access, and it does not need root. It needs the ability to execute code on the GPU. As SecurityWeek put it in its 7 April 2026 write-up, that is "any user with permissions to use the GPU".

So the question for your estate is not "are we on the cloud" but "can code we do not control run CUDA on a card that also runs something we care about". That covers more than public cloud instances:

Shared research and HPC clusters where multiple teams submit jobs to the same node. Notebook platforms and internal AI sandboxes where product teams get a GPU with no hypervisor boundary between them. Kubernetes GPU node pools with time-sliced device plugins. CI runners that build and test CUDA code. Rendering and inference boxes that a vendor or contractor can log into. Managed GPU rental where you cannot see who else lands on the host.

Single-tenant, whole-GPU passthrough with only your own code on the card is a materially different position. It is not risk-free, because your own workload may execute untrusted model code or user-supplied kernels, but the co-residency condition that the attack needs is gone.

Do the GPU sharing modes protect you?

This is the control question, and the honest answer is graded rather than binary.

Sharing mode	Isolation it provides	Position against this class of attack
Dedicated GPU per tenant (passthrough)	Full device, no co-residency	Strongest available today; removes the co-resident CUDA condition
MIG partitioning	Hardware partitioning with dedicated memory, cache and SMs	Better than time-slicing; MIG lives on the data-centre accelerator classes already assessed as likely resistant
Time-slicing (GPU Operator)	None; NVIDIA documents no memory or fault isolation between replicas	Weakest; NVIDIA's own docs say time-slicing trades MIG's memory and fault isolation for density
vGPU with time-sliced scheduling	Driver-mediated, still shares physical memory	Depends on the underlying partitioning; treat as time-slicing unless MIG-backed
Container-only separation on one GPU	Namespaces and cgroups, no device isolation	Software boundary against a hardware-layer attack; do not count it

NVIDIA's GPU Operator documentation is direct that time-slicing has no memory or fault isolation between replicas. That statement was written about noisy neighbours and crashes. It reads differently now.

What to change this month

There is no patch. NVIDIA has not assigned CVEs to the driver memory-safety bugs and has not issued a new bulletin, redirecting instead to Security Notice: Rowhammer - July 2025, which frames DRAM bit flips as an industry-wide hardware issue and recommends enabling System-Level ECC on supported GPUs. So the work is inventory and configuration.

Inventory by memory type, not by model name. Pull the GPU model and memory type for every card in the estate and split it into three buckets: HBM parts (A100, H100, H200 and newer), GDDR7 parts, and GDDR6 or GDDR6X parts. Ampere GDDR6 is the bucket that needs attention first.

Check ECC state rather than assuming it. NVIDIA says System-Level ECC is on by default on Hopper and Blackwell data-centre GPUs. That default does not extend to every workstation and inference part. Query it:

# per-GPU ECC mode, current and pending
nvidia-smi --query-gpu=index,name,memory.total,ecc.mode.current,ecc.mode.pending --format=csv

# full ECC detail including volatile and aggregate error counts
nvidia-smi -q -d ECC

# enable ECC on a specific GPU (requires a reboot or GPU reset to take effect)
sudo nvidia-smi -i 0 -e 1

Budget for the cost before you flip it fleet-wide. The CSA note puts the usable-VRAM reduction at roughly 6 per cent on Ampere workstation GPUs, and the Toronto researchers measured machine learning tasks running up to 10 per cent slower with ECC on. On a 48 GB card that is about 3 GB of model capacity, which can be the difference between one batch size and the next.

Kill co-residency where the hardware is in the flip-prone bucket. If a GDDR6 Ampere card is shared by time-slicing between parties who do not trust each other, move it to whole-GPU assignment or move the workload to an HBM part. Density is a cost decision; this is now also a boundary decision.

Treat UVM as a dependency worth measuring. The memory-massage primitives GPUBreach uses run through CUDA Unified Virtual Memory. Disabling UVM removes them, and also breaks or degrades a good deal of the ML stack, so this is a measure-then-decide item rather than a recommendation. Know which of your workloads actually needs UVM before someone proposes turning it off in an incident.

Ask your provider a specific question. Cloud and neocloud providers have had notice since November 2025. The useful question is not "are you affected". It is: on your Ampere-generation GDDR6 instance types, is System-Level ECC enabled, is a physical GPU ever shared between customers, and which driver branch are those hosts on. Answers vary a lot between hyperscalers and smaller GPU rental businesses, and the gap is worth knowing before you renew.

Watch for the CVE that has not been filed. Full technical disclosure of the driver bugs happened at IEEE S&P in May 2026 and gets a second airing at the Black Hat USA 2026 Briefings on 5-6 August. Monitor NVIDIA's product security page and the National Vulnerability Database, and pre-agree who owns the GPU driver update in your change process, because most estates have never had to answer that.

Mapping it to controls you already report against

If you carry a control framework, this maps cleanly enough that you can raise it without inventing a new category. The CSA note points at Cloud Controls Matrix IVS-01 and IVS-03 for infrastructure and virtualisation isolation between tenants, and TVM-06 for patch and vulnerability management of cloud infrastructure components, which is where GPU driver cadence belongs. For agentic systems, CSA's MAESTRO framework puts compute at Layer 6, and co-resident GPU attacks now belong in that layer's threat model next to hypervisor escape and container breakout.

The practical version for a security review: GPU driver patching is probably not in your patch SLA, GPU firmware is probably not in your asset inventory, and neither gap is defensible now that a hardware-layer attack routes through the driver.

India-specific considerations

Indian AI infrastructure has been built at speed and towards the value end of the accelerator range, which puts more GDDR6 in the fleet than a US-centric read would suggest. Domestic GPU rental has driven prices down hard, with capacity advertised from around ₹41 to ₹123 per hour depending on card and provider, and that competitive pressure rewards density: more tenants per card, more time-slicing, more shared clusters.

Two consequences follow. First, if you are choosing a domestic GPU provider for anything holding personal data or model IP, add the tenancy question to your due diligence alongside price and availability. Whole-GPU assignment costs more per hour and removes the co-residency precondition entirely.

Second, the Digital Personal Data Protection Act 2023 obliges a data fiduciary to take reasonable security safeguards. A host compromise that exposes another tenant's data is a security-safeguard failure, and the safeguard question will be asked about your architecture choices, not about NVIDIA's silicon. Our DPDP engineering playbook for Indian startups covers the wider obligation set; the point here is narrow. Tenancy is a safeguard decision.

For teams sizing capacity in the first place, our breakdown of India GPU cloud rental pricing for H100 and B200 and the wider AI compute capacity planning guide are the companion pieces; on the Kubernetes side, GPU resource claims under Dynamic Resource Allocation is where allocation policy is actually enforced, and the secure production agent blueprint for GKE covers the workload-isolation layer above it.

What we would not do

We would not rip out time-slicing across an entire fleet this quarter. Most GPU sharing inside a single trust boundary, one team, one workload, one set of engineers, is not the exposure being described. Reacting uniformly costs real throughput and buys nothing on cards that never flipped.

We would not describe ECC as a fix. The researchers say so themselves: ECC corrects single-bit flips and detects double-bit flips, and attack patterns that induce more than two flips have already been shown feasible on DDR4 and DDR5, where they can produce silent corruption instead of a clean fault. ECCploit in 2019 and ECC.fail in 2025 both made that case against server DDR4.

We would not wait for a CVE before doing the inventory. The inventory is what tells you whether you need to care at all, and it is a day of work.

FAQ

What is GPUBreach in one sentence?

GPUBreach is a Rowhammer attack disclosed on 6-7 April 2026 by University of Toronto researchers that corrupts NVIDIA GPU page tables in GDDR6 memory from an unprivileged CUDA kernel, then chains that access through memory-safety bugs in the NVIDIA kernel driver to obtain a root shell on the host.

Does keeping the IOMMU enabled protect me?

No, not against this specific chain. GPUBreach does not attempt unauthorised DMA. It corrupts driver-owned buffers that the IOMMU already permits the GPU to write, which triggers kernel-side memory-safety bugs. NVIDIA, AMD and Microsoft all still recommend keeping the IOMMU enabled, and the concurrent GeForge attack requires it disabled.

Are H100 and H200 accelerators affected?

The researchers assess NVIDIA data-centre accelerators using High Bandwidth Memory, including the A100, H100 and H200, as likely resistant because HBM ships with on-die ECC enabled by default. The demonstrated exploit ran on an RTX A6000 with GDDR6. That assessment is not a vendor guarantee, so track it as likely rather than settled.

Should I enable ECC on every GPU right now?

Enable it on GDDR6 workstation and inference cards that support it and are shared between parties, after budgeting the cost. The Cloud Security Alliance note puts usable VRAM loss at roughly 6 per cent on Ampere workstation GPUs, and the researchers measured machine learning tasks up to 10 per cent slower with ECC active.

Has NVIDIA issued a patch or a CVE?

Not as of this writing. NVIDIA assigned no CVEs to the driver memory-safety bugs and issued no new bulletin, directing readers to its July 2025 Rowhammer security notice, which treats DRAM bit flips as an industry-wide hardware issue and recommends enabling System-Level ECC on supported GPUs. Monitor NVIDIA product security for changes.

Which GPU sharing mode is safest?

Dedicated whole-GPU assignment per tenant, because it removes the co-residency the attack requires. MIG partitioning gives hardware-level memory and fault isolation on the data-centre accelerator classes already assessed as likely resistant. NVIDIA documents that time-slicing provides no memory or fault isolation between replicas at all.

Who found this and when was NVIDIA told?

Chris S. Lin, Yuqin Yan, Guozhen Ding, Joyce Qu, Joseph Zhu, David Lie and Gururaj Saileshwar at the University of Toronto. They disclosed to NVIDIA on 11 November 2025 and later to Google, AWS and Microsoft. Google awarded a $600 bug bounty. The paper appears at the 47th IEEE Symposium on Security and Privacy.

What is the fastest useful action for a small team?

Inventory every GPU by memory type, then check ECC state with nvidia-smi rather than assuming a default. If any Ampere-generation GDDR6 card is time-sliced between parties who do not trust each other, move that workload to whole-GPU assignment or to an HBM accelerator. That sequence takes about a day.

How eCorpIT can help

eCorpIT is a CMMI Level 5 and ISO 27001:2022 certified technology organisation in Gurugram, and our senior engineering teams build and run GPU and Kubernetes platforms for AI workloads. We can inventory a GPU estate by memory type and tenancy model, test the ECC and throughput trade-off on your own workloads instead of a benchmark, and redesign allocation so that untrusted code and sensitive workloads stop landing on the same card. We design platforms aligned with DPDP Act 2023 and ISO 27001 requirements. Talk to us at /contact-us/ if you want that review done before someone asks you for it in a security questionnaire.

References

1. GPUBreach: Privilege Escalation Attacks on GPUs using Rowhammer, University of Toronto SITH Lab project page, 2026.
2. CSA research note: GPUBreach - GDDR6 RowHammer achieves full CPU privilege escalation, Cloud Security Alliance AI Safety Initiative, 7 April 2026.
3. GPUBreach: Root Shell Access Achieved via GPU Rowhammer Attack, Eduard Kovacs, SecurityWeek, 7 April 2026.
4. New GPUBreach Attack Enables System Takeover via GPU Rowhammer, Bill Toulas, BleepingComputer, 6 April 2026.
5. New GPUBreach Attack Enables Full CPU Privilege Escalation via GDDR6 Bit-Flips, The Hacker News, 7 April 2026.
6. How three U of T researchers discovered a GPU vulnerability that could threaten AI models, University of Toronto News, 3 September 2025.
7. GPUHammer: Rowhammer Attacks on GPU Memories are Practical, Lin, Yan, Ding, Qu, Zhu, Lie and Saileshwar, USENIX Security Symposium 2025.
8. GPUHammer project page, University of Toronto, 2025.
9. Security Notice: Rowhammer - July 2025, NVIDIA Customer Help, July 2025.
10. Time-Slicing GPUs in Kubernetes, NVIDIA GPU Operator documentation, accessed August 2026.
11. Black Hat USA 2026: Rowhammer Hits NVIDIA GPUs as Government Takes the Keynote Stage, Devin Culbertson, Tech Times, 31 July 2026.
12. New GeForge and GDDRHammer attacks can fully infiltrate your system through NVIDIA's GPU memory, Tom's Hardware, April 2026.
13. NVIDIA Product Security, NVIDIA, accessed August 2026.
14. GPU cloud India pricing, JarvisLabs, accessed August 2026.
15. Rent NVIDIA L40S GPU in India, E2E Networks, accessed August 2026.

Last updated: 4 August 2026.