GPUBreach Attack Gives Hackers a Root Shell on NVIDIA GPUs

NVIDIA GPUs with GDDR6 memory can be used to take full control of a system, including a root shell, bypassing hardware defenses that were supposed to stop exactly this. Three independent research teams published GPU attack research at the same time. One of them goes further than anything before it. There is currently no fix for consumer GPUs. 😏

The attack is called GPUBreach, and it comes from researchers at the University of Toronto. To understand why it matters, it helps to know what Rowhammer is, because that is where this starts.

DRAM memory is built from rows of tiny cells packed extremely close together. When you hammer the same row with repeated memory accesses over and over again, the heat and electrical noise starts leaking into the rows next door and flips bits that nobody was supposed to be able to touch. A 1 becomes a 0. A 0 becomes a 1. In memory that does not belong to you. This has been a known problem in CPU memory for over a decade. The question nobody had fully answered was whether GDDR6, the memory inside modern NVIDIA GPUs, was just as vulnerable.

It is.

The same research group at Toronto published a paper in July 2025 called GPUHammer, which showed that Rowhammer attacks on NVIDIA GDDR6 are practical. A single strategic bit flip could take an AI model from 80% accuracy down to essentially zero. NVIDIA responded by publishing a security notice and telling users to enable System-Level ECC. Most consumer GPUs cannot do that at all.

GPUBreach is the follow-up, and the threat is a different category entirely.

Where GPUHammer caused data corruption, GPUBreach causes privilege escalation. The researchers reverse-engineered the NVIDIA driver to understand exactly how GPU page tables are allocated and stored inside GDDR6 memory. Page tables are basically the address book of the GPU. They keep track of which piece of memory belongs to which process, and they are what keeps one program from reading another program’s data. Control the page tables and you control everything the GPU can see and touch.

The attack uses a timing trick on how the GPU manages its memory to detect exactly when a new page table region appears. It is like listening for the sound of a safe opening so you know exactly when to strike. By carefully freeing and refilling memory in the right order, the attacker pushes a GPU page table into position right next to a row that is known to flip. Like parking a car in exactly the right spot. One targeted Rowhammer bit flip later, an unprivileged CUDA kernel has arbitrary read and write access across the entire GPU memory space.

That alone is serious. But GPUBreach does not stop at the GPU.

Getting from the GPU to the CPU is where this attack separates itself from everything that came before it. The standard defense against this kind of hardware attack is called IOMMU, a unit that restricts which physical memory addresses a GPU is allowed to access through direct memory access. NVIDIA recommends keeping it enabled. AMD recommends keeping it enabled. Microsoft recommends keeping it enabled. Two of the concurrent research papers, GDDRHammer from UNC Chapel Hill and GeForge from Purdue, both require IOMMU to be disabled to reach the CPU. With IOMMU on, they stop at the GPU.

GPUBreach does not try to go around IOMMU. It goes through the NVIDIA driver instead.

The compromised GPU uses its normal, permitted access to write into parts of CPU memory that the IOMMU explicitly allows, because those areas belong to the NVIDIA kernel driver. Think of it as slipping a poisoned note into someone’s inbox instead of breaking down the front door.

The attack then corrupts the data inside those trusted driver areas. When the NVIDIA driver picks up that poisoned data and processes it on the CPU, it triggers out-of-bounds writes. The attacker gets an arbitrary kernel write primitive. From there, a root shell. No hardware alarms. The IOMMU sees exactly what it expects to see.

Here is what becomes possible once the full chain completes.

• → Secret cryptographic keys can be pulled from NVIDIA’s cuPQC library while key exchanges are actively happening in GPU memory. cuPQC is the library NVIDIA built to accelerate post-quantum encryption, the kind designed to protect communications against future quantum computers. GPUBreach can steal those keys now, during the operation itself.
• → LLM weights can be leaked from GPU DRAM. The weights of a large language model represent billions in training costs and proprietary architecture. If a model is running on a shared GPU environment, another tenant’s workload could read them out.
• → AI model accuracy can be silently destroyed. By modifying a single branch inside NVIDIA’s cuBLAS library in GPU memory, a model goes from 80% accuracy to zero. No error messages. No crash. No indication that anything went wrong. The model keeps running and producing output. That output is just meaningless.
• → Full root shell on the host, with IOMMU enabled.

On the question of which hardware is affected, the picture is clearer than most coverage suggests. The confirmed vulnerable cards are NVIDIA GPUs using GDDR6 memory, primarily from the Ampere generation. The RTX 3060 and the RTX A6000 are the two models with fully demonstrated exploit chains. GDDRHammer alone tested 25 GDDR6 GPUs and found bit flips in the majority. GDDR6X cards like the RTX 3080 showed no bit flips in testing. GDDR7 cards, including the RTX 5090, use always-on on-die ECC that is not configurable by the user, and those were not found vulnerable to current techniques.

For consumer desktop and laptop GPUs running GDDR6, the researchers stated it plainly: there are no known mitigations. ECC is not available on gaming GPUs. The only path to protection is a driver patch addressing the underlying memory-safety bugs that GPUBreach exploits, and that patch does not exist yet.

Now here is the part that tells you everything about how the industry handles this.

The University of Toronto researchers reported GPUBreach to NVIDIA, Google, AWS, and Microsoft on November 11, 2025. That is almost five months ago. Google acknowledged the report and paid a bug bounty. The amount was $600. For context, Google pays up to $250,000 for a critical Chrome sandbox escape. For an attack that roots machines running AI infrastructure, steals post-quantum keys, and extracts model weights from shared cloud hardware, they paid six hundred dollars.

To put that in perspective even further: NVIDIA is worth close to a trillion dollars. Google is worth over two trillion. And the researchers who spent months finding a flaw that protects their customers and their infrastructure walk away with $600. Bug bounty programs are supposed to reward the people who do this work. At these numbers, it is not a reward. It is an insult. These findings deserve better, and the industry knows it. They should be ashamed.

NVIDIA has not assigned a CVE. They have not released a new security notice specifically for GPUBreach. They pointed to their existing Rowhammer notice from July 2025, which predates this research, and said they may update it. That is the current status.

The reproduction code and full technical paper go live on April 13 when the GitHub repository opens at sith-lab/gpubreach. That is next week. The full presentation follows at the IEEE Symposium on Security and Privacy in San Francisco in May. The race to patch is now.

The detail worth paying attention to here is that three independent teams reached the same conclusion at the same time. GPUBreach from Toronto, GDDRHammer from UNC Chapel Hill and Georgia Tech, GeForge from Purdue and Rochester. All three will present at the same IEEE Symposium on Security and Privacy in May 2026. When multiple teams independently converge on the same attack surface, it generally means that surface has been sitting there long enough for anyone with the right skills to find it.

Worth noting: this attack requires unprivileged code execution on the GPU to begin. That is not a drive-by attack from the internet. For cloud environments where every customer gets GPU compute access by default, that bar is already cleared the moment someone spins up an instance.

Here is what to do depending on your situation.

If you have a workstation or enterprise GPU with GDDR6 like the RTX A6000:

• → Enable System-Level ECC via nvidia-smi -e 1 and reboot. Not a complete fix, but it raises the bar.
• → Keep IOMMU enabled. It stops GDDRHammer and GeForge even if it does not stop GPUBreach.
• → Watch NVIDIA’s security advisories for a driver update that addresses the driver-level memory-safety bugs.
• → On shared GPU environments, review tenant isolation policies before April 13 when the reproduction code goes public.

If you have a consumer gaming GPU with GDDR6:

• → There is currently no mitigation available on your hardware.
• → Keep NVIDIA drivers updated and watch for a patch.
• → Avoid running untrusted CUDA code on machines where sensitive data or keys are present.

If you are on GDDR7 hardware like the RTX 5090, or HBM-based data center cards:

• → Current research does not demonstrate a working exploit on your hardware.

Understanding how attackers escalate from a foothold to full system control is exactly what I cover in my ethical hacking course, including exploitation techniques, privilege escalation, network attacks, and the full attack chain from reconnaissance to complete system compromise.

• → Join my complete ethical hacking course

(The link supports me directly as your instructor!)

Hacking is not a hobby but a way of life.