If you run shared GPU infrastructure — a Kubernetes cluster scheduling nvidia.com/gpu to more than one team, a CI/CD fleet that trains or benchmarks on contributor-submitted code, a rented A6000 in a cloud ML platform — you were told in April to enable ECC and move on. That advice is now four months old and wrong. On August 27, researchers at the University of Toronto published GPUThor, a Rowhammer variant that induces bit flips on ECC-protected NVIDIA GDDR6 memory reliably enough to walk the same page-table-corruption chain that got attackers a root shell in April, ECC turned on the whole time.

This piece isn’t about GPUThor’s physics, which are covered elsewhere. It’s about what changes on Monday morning for the people who actually schedule GPU workloads: what’s exposed, what isn’t, and which of the mitigations your team adopted after the April disclosures were never going to survive contact with a better attack.

The lineage, compressed

Four disclosures in thirteen months, each closing a gap the last one left open:

  • GPUHammer (July 2025, University of Toronto). First Rowhammer bit flips ever demonstrated on discrete GPU memory — 1,171 flips induced on a consumer RTX 3060. The headline damage was AI model integrity: a single targeted bit flip in a deployed ImageNet model dropped accuracy from 80% to 0.1%. NVIDIA’s response was to point at ECC, present on workstation and datacenter cards but absent on GeForce consumer silicon.
  • GPUBreach, GDDRHammer, GeForge (April 2, 2026, IEEE S&P — three independent teams). All three showed that a Rowhammer-induced bit flip in a GPU page table is enough to escalate from an unprivileged CUDA kernel to full host compromise. GPUBreach’s distinguishing feature was doing this without requiring IOMMU to be disabled, which is what made “enable ECC and keep IOMMU on” the consensus mitigation industry-wide. None of the three defeated ECC directly — they relied on ECC being absent or on chaining through driver memory-safety bugs.
  • GPUThor (August 27, 2026, University of Toronto again). Defeats ECC directly. The same authors who built GPUHammer came back and broke the fix everyone adopted in response to their own earlier paper.

That last point is worth sitting with. This isn’t a new class of bug being found by a rival team scoring a point — it’s the original research group demonstrating that the industry’s chosen mitigation for their first finding doesn’t hold. When your fix comes from vendor guidance issued four months ago instead of from primitives that don’t get patched, budget for it not holding.

What non-uniform hammering actually does

Target Row Refresh (TRR) works by watching for one row getting hammered unusually hard and refreshing its neighbors preemptively. Every prior GPU Rowhammer attack, including GPUHammer, hammered the aggressor row and a set of decoy rows at roughly the same rate, trying to keep the pattern under TRR’s detection threshold while still landing enough activations to flip a bit. That’s a narrow needle to thread, which is part of why GPUHammer needed 21.9 hours on average to find one exploitable flip.

GPUThor’s contribution is a six-refresh-interval hammering pattern that activates the aggressor row far more aggressively than the decoys — about 110,000 aggressor-row activations per refresh window, 6.6x the effective intensity of GPUHammer’s approach — while still evading TRR. It gets away with this by exploiting two GPU memory-controller behaviors that weren’t previously documented: how the controller coalesces repeated back-to-back requests to the same row, and the actual firing cadence of TRR versus its nominal spec. Tuned against those two behaviors, the attack produces 72,000 to 377,000 bit flips per gigabyte on unprotected memory and cuts time-to-exploitable-flip from 21.9 hours to about 1.1 minutes.

Against ECC-enabled cards, sustained hammering in the researchers’ tests produced 387 double-bit errors — which ECC can detect but not correct, so the safe failure mode is a fault, not silent corruption — and two triple-bit errors, which ECC’s correction logic miscorrected, silently writing bad data back into memory instead of failing safely. Two triple-bit events sounds small next to 387 double-bit ones, but it’s not zero, and the same page-table-corruption chain GPUBreach demonstrated in April only needs one useful flip in the right structure. Bring that timing down to 1.1 minutes and the two-flips-in-a-long-run problem stops being a research curiosity.

No CVE has been assigned. Attack code is scheduled for public release November 15, 2026, at ACM CCS — you have roughly eleven weeks before this stops being a paper and starts being a tool.

Who’s actually exposed

Confirmed vulnerable: Ampere-generation NVIDIA workstation cards with GDDR6 — RTX A4000, A4500, A5000, A6000. These are the cards that ended up in render farms, on-prem ML workstations, and GPU-passthrough VMs specifically because teams moved to them for ECC support after GPUHammer. Consumer GeForce cards have no ECC to begin with and were never protected. Datacenter cards using HBM — A100, H100, H200, B100/B200 — are out of scope; HBM’s on-die ECC is architecturally distinct from GDDR6’s memory-controller-side ECC and isn’t affected by this technique.

The exposure that matters operationally isn’t “do we own A6000s.” It’s narrower: does any environment let untrusted or semi-trusted code submit CUDA kernels onto GDDR6 hardware that’s shared with anything you care about? Three shapes of that show up constantly in infra:

  1. Kubernetes clusters scheduling GPU workloads across teams or tenants without hard partition boundaries.
  2. CI/CD runners with GPU access, where a pull request from an external contributor can trigger a training or benchmark job.
  3. Rented cloud GPU capacity where the provider’s isolation model is opaque to you.

If none of those apply — single-tenant workstations, dedicated per-team hardware, no external code ever reaches the card — this is a lower-priority item for your fleet. If any of them do, keep reading.

The isolation boundary that actually matters: MIG versus time-slicing

This is the part most teams get backwards, and it’s the single highest-leverage thing to check first. NVIDIA’s Multi-Instance GPU (MIG) technology partitions a physical GPU into up to seven instances, each with its own dedicated memory controller, L2 cache slice, and DRAM address bus. That’s not a software quota — it’s separate physical paths through memory. A Rowhammer attack from one MIG instance cannot hammer DRAM rows belonging to another instance, because they’re not on the same controller.

Time-slicing (and MPS) does not do this. It shares the same physical memory controller and DRAM banks across all tenants scheduled onto the card, just with the compute scheduler switching who’s running. Rowhammer doesn’t care about your compute scheduler — it cares about which physical rows get hammered, and under time-slicing, every tenant’s data lives in the blast radius of every other tenant’s kernel.

Concretely:

  • MIG is available on datacenter Ampere/Hopper/Blackwell cards (A100 and later) and is unaffected by GPUThor’s technique for two independent reasons: those cards use HBM, and MIG’s partition boundaries would isolate the attack even if they didn’t.
  • RTX/RTX-A workstation cards — the ones actually vulnerable — do not support MIG. Your only sharing options on an A4000–A6000 are time-slicing or MPS, neither of which provides any isolation against this attack.

That means the mitigation isn’t “turn on MIG” for the affected hardware — it’s structurally unavailable there. The actual conclusion is starker: RTX/RTX-A GDDR6 workstation cards cannot be safely time-sliced across tenants who don’t already trust each other. If your Kubernetes GPU operator config has time-slicing enabled on nodes carrying A4000–A6000 hardware and those nodes serve more than one team, that configuration is now a known attack surface, not a capacity optimization.

1
2
3
4
5
6
7
8

# nvidia-device-plugin ConfigMap — audit for this pattern on any node
# pool running A4000/A4500/A5000/A6000 GPUs shared across tenants
version: v1
sharing:
  timeSlicing:
    resources:
    - name: nvidia.com/gpu
      replicas: 4   # <- 4 tenants sharing one physical DRAM bus, no isolation

Find every node pool running this pattern on GDDR6 workstation silicon and either move to single-tenant scheduling (node affinity keyed to team, no shared replica count) or move the workload to HBM datacenter cards where MIG is actually available.

What to do this week

1. Inventory the actual exposure, not the whole fleet. Pull GPU model from your node labels or nvidia-smi -L fleet-wide and cross-reference against the affected list (A4000, A4500, A5000, A6000, plus any GeForce cards anywhere near shared infrastructure). Then cross-reference that list against scheduling config: which of those nodes are single-tenant, and which have time-slicing or MPS sharing enabled across more than one team or untrusted CI job.

2. Pull GDDR6 workstation cards out of untrusted multi-tenant rotation now. Not “monitor more closely” — actually stop scheduling untrusted or cross-team CUDA kernels onto A4000–A6000 hardware that’s shared. This includes CI/CD runners that execute contributor-submitted code; treat “someone else’s PR gets to run a CUDA kernel on this card” as equivalent to “someone else’s PR gets to run on this card unsandboxed,” because that’s what it now is.

3. Enable both ECC and IOMMU/DMA isolation — but budget for both as slowing the attacker, not stopping them. NVIDIA’s updated guidance is explicit that neither alone is sufficient, and after GPUThor, the honest framing is that neither together is sufficient against a well-resourced attacker either — they raise the bar, they don’t remove the risk. Don’t let “we enabled both” become the closing line in a risk register entry; it’s a mitigation for capability-limited attackers, not a fix.

4. Monitor ECC error telemetry as an intrusion signal, not background noise. A rising rate of corrected or uncorrected ECC errors on a card that’s supposed to be running steady-state inference or training is now a leading indicator of active hammering, and 1.1-minute time-to-flip means you need alerting with a short window, not a daily digest.

1
2
3

# per-GPU ECC error rate — wire into DCGM/Prometheus with a short-window alert
nvidia-smi --query-gpu=uuid,ecc.errors.corrected,ecc.errors.uncorrected \
  --format=csv -l 30

1
2
3
4
5
6
7
8
9

# example Prometheus alerting rule — tune thresholds to your fleet's baseline
- alert: GPUEccErrorRateAnomaly
  expr: increase(DCGM_FI_DEV_ECC_DBE_VOL_TOTAL[5m]) > 5
  for: 2m
  labels:
    severity: high
  annotations:
    summary: "Uncorrectable ECC double-bit error spike on {{ $labels.gpu }}"
    description: "Possible active Rowhammer-class hammering. Correlate with recently scheduled CUDA workloads on this node."

A double-bit error count near zero in steady state that suddenly climbs correlates strongly with hammering behavior — legitimate training and inference workloads don’t generate this pattern. Treat a spike as an incident: identify what was scheduled on that card in the preceding minutes, not hours.

5. Revisit procurement for anything buying shared GPU capacity going forward. If a fleet’s purpose includes running untrusted or cross-tenant CUDA code, HBM-based datacenter cards with MIG support are the only architecture with an actual isolation boundary against this attack class today. GDDR6 workstation cards are fine for single-tenant, trusted-code use — render farms, dedicated ML workstations — but stop specifying them for anything with a multi-tenancy requirement in the RFP.

What not to do

Don’t treat this as a network problem. Nothing about Rowhammer requires network access — the attacker needs to get a CUDA kernel scheduled onto the same physical memory as the target, which is exactly what shared GPU infrastructure is built to allow. “It’s not internet-facing” buys you nothing here.

Don’t treat “we enabled ECC in April” as closed. If your incident response or risk-register process treated the April GPUBreach disclosures as resolved once ECC was flipped on, that ticket needs to be reopened, not because a new CVE exists — none does — but because the assumption behind closing it no longer holds.

Don’t wait for a CVE or a patch. There isn’t a software fix for DRAM refresh physics, and NVIDIA has not shipped — and structurally cannot ship — a driver patch that changes how many electrons leak off a capacitor when its neighbor gets hammered. The fix is architectural: physical isolation (MIG) or scheduling isolation (single-tenant), not a version bump.

The takeaway

The pattern across GPUHammer → GPUBreach/GDDRHammer/GeForge → GPUThor is a research group and its peers steadily removing every excuse for treating GPU DRAM as trustworthy in a multi-tenant context. GPU vendors are roughly a decade behind CPU vendors on hardware-level side-channel defense, and infrastructure teams inherited that gap without being told it existed until last year. The practical lesson isn’t “enable the next mitigation NVIDIA publishes” — it’s that any mitigation resting on DRAM-level protections (ECC, TRR) should be assumed temporary, and the durable fix is architectural: don’t let untrusted code share a physical memory bus with anything that matters. MIG gives you that boundary where it’s available. Single-tenant scheduling gives it to you everywhere else. Time-slicing a GDDR6 workstation card across tenants who don’t already trust each other no longer belongs in a defensible architecture, and it hasn’t since April — GPUThor just removed the last reason to pretend otherwise.

Concrete next steps, in order: inventory GDDR6 workstation GPUs against your scheduling config; pull them out of untrusted multi-tenant rotation; wire ECC error-rate alerting with a sub-five-minute window; stop specifying GDDR6 workstation cards for any new multi-tenant capacity; treat MIG-capable HBM datacenter cards as the only currently-defensible option for shared, untrusted CUDA workloads.