GPUHammer grew up: three new Rowhammer attacks take full control of Nvidia machines

Rowhammer jumped from DRAM research papers to real-world exploits ten years ago. This month, it jumped from CPU memory to the GPU. Three new papers at the 47th IEEE Symposium on Security & Privacy in 2026, GeForge, GDDRHammer, and GPUBreach, chain GPU bit flips into full host takeover. They build on the University of Toronto team’s GPUHammer from USENIX Security 2025, which proved the primitive was possible on a discrete Nvidia GPU.

Why now? Because the only interesting question left was whether you could ride the bit flip out of the GPU into the kernel. The 2026 papers answer yes.

What is Rowhammer, again

DRAM packs memory cells into rows. Reading a row repeatedly can leak charge into neighbors, flipping bits you don’t own. Rowhammer is the generic name for attacks that exploit that physics to corrupt memory an attacker shouldn’t be able to touch. On CPU DDR memory, refresh-rate mitigations and Target Row Refresh bought a few years of peace, then researchers broke those too. It’s a running battle.

The assumption on GPUs was that discrete cards were harder to hammer because GDDR memory has different timing and the programming model doesn’t give you the cache-flush primitives CPU Rowhammer depends on. The Toronto team showed that was wrong. GPUHammer induced 1,171 exploitable bit flips on an RTX 3060, and the follow-on work turned those flips into real capabilities.

What the 2026 papers actually do

Three separate teams extended GPUHammer in different directions. The precise paper attributions shake out at IEEE S&P, but the primitives are what matter:

GeForge and GDDRHammer are the primitive-level upgrades. They find more reliable ways to hammer GDDR6 rows despite the GPU’s memory controller behavior, using the compute stack that AI workloads already hit. That’s important because the original attack was more fragile than CPU Rowhammer.

GPUBreach is the exploit chain. Attackers use bit flips to corrupt GPU page tables, gaining arbitrary read/write in GPU memory. From there they chain vulnerabilities in the Nvidia kernel driver to escalate to root on the host, even with IOMMU protections enabled. That last clause is what’s new. IOMMU was supposed to be the defense in depth that kept a rogue GPU from owning the CPU. It isn’t.

The Aviatrix research summary is explicit about the threat model: cloud AI infrastructure, multi-tenant GPU deployments, HFT systems, GPU-accelerated medical imaging, and avionics are the most exposed. That list is broader than it first looks. Every one of those segments has been migrating to shared GPU pools for the last three years on cost grounds.

A quick note on naming, because the attack taxonomy got noisy fast. GPUHammer (2025) is the foundation primitive. GeForge sharpens the hammering technique. GDDRHammer generalizes across GDDR6 configurations. GPUBreach is the end-to-end host-takeover demonstration. They’re complementary, not competing.

Researcher Gururaj Saileshwar summed up the scope to CSO Online: any GPU with GDDR6 is potentially in scope. That includes most of the RTX 20, 30, 40, and 50 series cards gamers own, plus the A-class workstation parts.

Who actually gets hurt

Ordinary gaming PCs and single-user workstations are not the target. The attacks require an attacker’s code to run on the same GPU at the same time as yours. Three deployment shapes are genuinely at risk:

• Multi-tenant cloud GPUs. Shared model-serving pools, neocloud Jupyter environments, GPU-as-a-service offerings that don’t do full device isolation between customers.
• Internal shared GPU clusters. Kubernetes with device plugins splitting a card across pods, ML research clusters with multi-user SSH, CI runners that fan out across a single GPU.
• Edge and robotics deployments where a GPU runs both trusted control code and downloaded ML models.

The pattern is the same: untrusted code sharing a physical GPU with trusted code. If you’re running a 4090 at home to play Cyberpunk, you’re fine.

ECC is the real shield, and it’s partially deployed

Nvidia’s official guidance, quoted in CSO’s coverage, is blunt: use professional and data-center products with ECC enabled. ECC detects and corrects single-bit flips in GDDR6 and catches most of what Rowhammer does on a hammered row.

The coverage map is lumpy. Hopper (H100, H200) and Blackwell (B100, B200) ship with ECC on by default in data-center configurations. The A-class workstation parts support ECC but often ship with it off. Consumer GeForce cards don’t expose ECC at all. That’s why the Toronto team’s RTX 3060 demo landed: on a consumer GDDR6 board, bit flips are a primitive and not an anomaly.

ECC isn’t a guarantee either. It catches single-bit errors. Multi-bit flips in the same row sneak through, and the attack papers show practical techniques to induce them. Refresh-rate increases can push the difficulty up. Both cost real performance.

Why detection tooling isn’t going to save you

Endpoint security monitors CPU syscalls, process trees, and file system activity. It does not watch GPU memory. A Rowhammer primitive that turns into code execution via the driver pivots into the CPU world only after the compromise is complete. By that point you’re reading the symptom, not the cause.

That’s not a knock on the EDR vendors. Watching billions of GDDR access patterns at line rate is a product that doesn’t exist yet, and CrowdStrike or SentinelOne aren’t well-placed to build it. GPU telemetry is a Nvidia-side problem, and Nvidia’s stance is pretty clearly “use ECC parts and move on.”

What IT teams should actually do this quarter

Cleanly separated from the science, the operational playbook is short.

1. Inventory GPU multi-tenancy. Name the pools where untrusted code runs alongside trusted code on the same physical device. Jupyter-as-a-service, shared CI, shared model serving.
2. Turn ECC on wherever it’s supported and was left off. That’s the single largest blast-radius reduction available without new hardware.
3. Prefer data-center parts for multi-tenant AI workloads. If you’re running a sharded A6000 pool for customer inference, pricing out Hopper or Blackwell replacements is now a security argument, not just a perf one.
4. Segment sensitive workloads onto dedicated cards. No mixing customer tenants, no mixing dev and prod, no mixing downloaded models with signing keys.
5. Patch the Nvidia driver religiously. GPUBreach chains through driver CVEs. Driver rev is now a tier-one security control, not a “we’ll get to it.”

What this means for you

If you’re a developer: this probably doesn’t change your laptop. It probably does change your assumptions about “my container is isolated on this shared GPU.” It isn’t, not against motivated attackers, and the 2026 papers are the cleanest proof of that to date. If you ship inference on a neocloud that doesn’t publish its tenant-isolation model, ask them what they do about GPU Rowhammer in their next review. Anyone saying “we use IOMMU” is giving last year’s answer to this year’s question.

If you run infra: the near-term action is turning on ECC everywhere it’s supported, and auditing which pools are multi-tenant. The medium-term action is migrating high-sensitivity AI workloads to Hopper or Blackwell class cards where ECC is default-on. It’s a money conversation, but the analogy is real: running customer inference on consumer-class GPUs in 2026 is about where running customer web workloads on shared-tenant bare metal was in 2018. It’ll age poorly.

One thing not to miss: this is the same year researchers cut the quantum-computing timeline to 2029 and the Trivy supply-chain attack reshaped CI security. Hardware-side isolation and supply-chain integrity are both getting re-opened at the same time. Budget accordingly.