GPUBreach: Rowhammer Attack on NVIDIA GPUs Takes Center Stage at Black Hat 2026

What happened

A team from the University of Toronto has demonstrated an attack that starts inside a graphics card and ends with a root shell on the machine hosting it. They call it GPUBreach. The work was published at IEEE S&P 2026 and is being presented this week at Black Hat USA 2026, the security conference running August 1 to 6, 2026 in Las Vegas.

The headline claim is narrow and precise. Earlier GPU Rowhammer results this year, including the concurrent GDDRHammer and GeForge papers, could flip bits inside GPU memory or escalate privileges only when a key hardware defense was turned off. GPUBreach reaches a full CPU root shell with the Input-Output Memory Management Unit, the IOMMU, left enabled. That is the configuration most servers actually run.

The authors are Chris S. Lin, Yuqin Yan, Guozhen Ding, Joyce Qu, Joseph Zhu, David Lie and Gururaj Saileshwar. Their proof of concept ran on an NVIDIA RTX A6000, a workstation and server card built on GDDR6 memory. The code is public on GitHub under the lab's sith-lab/gpubreach repository.

How the attack works

Rowhammer is an old idea with a new target. Repeatedly reading or writing one row of memory cells can leak charge into a neighboring row and flip a bit that nobody wrote. It was first shown on CPU DRAM more than a decade ago. GPUBreach carries the same physics onto the GDDR6 chips that sit around a GPU die.

Flipping a random bit is not an exploit on its own. The hard part is aiming. The researchers reverse-engineered NVIDIA's driver to find where the GPU keeps its page tables, the maps that translate a program's addresses into physical memory, and learned that they live in contiguous 2MB regions. Hammering the right neighbor lets them corrupt a page table entry and point a memory access somewhere it was never allowed to go.

From there the attack pivots off the card. A corrupted page table gives arbitrary read and write access inside GPU memory. The team then chains that into memory-safety bugs in the GPU driver to perform out-of-bounds writes inside buffers the driver already trusts. The corrupted driver state yields a kernel write primitive, and the kernel write primitive yields root. The IOMMU, which is supposed to stop a device from writing wherever it likes in host memory, does not block the path because the escalation is laundered through code the kernel already trusts.

What an attacker can reach

The root shell is the loud result. The quieter ones matter just as much for anyone running shared hardware. Because the attack grants arbitrary access to GPU memory, the paper shows it reading across process boundaries on the same card. In a world where one physical GPU is sliced between tenants, that is the boundary the whole model depends on.

The demonstrated impacts, per the researchers, include:

• Cross-process memory theft: reading another workload's data resident on the same GPU.
• Post-quantum key leakage: extracting secrets from the cuPQC cryptography library.
• Model tampering: corrupting math results through cuBLAS to steer a machine-learning model's output.
• Weight extraction: lifting the parameters of a large language model out of GPU memory.

That last item is the one AI operators will read twice. A model's weights are often the most expensive thing on the card.

Who is actually exposed

This is not a reason to worry about your gaming PC. GPUBreach assumes an attacker can already run unprivileged code on the machine and needs physical-adjacency to the memory chips through timing, not a click on a link. On a single-user desktop, an attacker with a local foothold usually has easier routes to root than hammering GDDR6.

The real exposure is multi-tenant infrastructure: cloud GPU instances, shared AI training clusters, rented inference capacity. There, running untrusted code next to someone else's workload on the same physical card is the business model, and the isolation between tenants is exactly what the attack erodes. That is why the disclosure went to the cloud providers as well as the vendor.

The mitigation, and its limits

The recommended defense is error-correcting code memory. ECC can catch and repair a single-bit flip, which is what most Rowhammer attempts produce. NVIDIA's own security notice from July 2025 already advises enabling ECC on server and workstation GPUs, and that guidance stands.

The catch is in the word "single." ECC that corrects one bit can be defeated by a pattern that flips several bits in the same protected word, and Rowhammer research has spent years learning to produce exactly those patterns. So ECC raises the cost of the attack rather than closing it, and it carries a performance and capacity tax that some deployments turn off by default. The honest summary: turn ECC on if you run shared GPUs, and do not treat it as a wall.

The researchers followed coordinated disclosure. They notified NVIDIA on November 11, 2025, then Google, AWS and Microsoft. Google issued a bug bounty for the report, a $600 award.

What happens next

GPUBreach is the third GPU Rowhammer result to surface in 2026, alongside GDDRHammer and GeForge, and the pattern is the point. A hardware weakness that was treated as a CPU-memory problem is now clearly a GPU-memory problem too, on the exact chips the AI build-out is buying by the crate.

Expect the pressure to land on two places. On silicon, the fix that actually helps is stronger in-memory protection in future GDDR and HBM generations rather than software patches. On operations, cloud GPU providers now have to answer how they isolate tenants on a shared card when the memory itself can be coaxed into lying. Neither answer arrives by the time Black Hat's show floor closes on August 6, 2026, but the questions will outlast the conference. The full paper and demonstrations are posted at gpubreach.ca.