Rowhammer Breaks NVIDIA ECC: Root Shell in Under Two Minutes Before Code Goes Public

University of Toronto researchers disclosed a new hardware attack on August 25, 2026 that defeats the error-correcting code (ECC) protection NVIDIA has been recommending as the primary Rowhammer defense — and cuts the time to achieve a root shell on a compromised host from nearly 22 hours to roughly 1.1 minutes. The attack, called GPUThor and accepted at the ACM Conference on Computer and Communications Security (CCS '26) in The Hague, targets four Ampere-class NVIDIA workstation GPUs that are deployed across commercial cloud GPU fleets and AI research clusters worldwide. The exploit code is scheduled for release November 15, 2026 , when the CCS '26 conference opens — giving cloud operators a preparation window that is already narrowing.

TechTimes has previously reported that enabling System-Level ECC was NVIDIA's primary mitigation against GPU Rowhammer attacks. GPUThor's central finding changes that assessment: on ECC-enabled hardware, the attack generates errors that the ECC logic silently "repairs" to incorrect values, introducing data corruption with no error flag raised and no alert visible to monitoring systems.

GPUThor targets four Ampere workstation GPUs with GDDR6 : the RTX A4000, A4500, A5000, and A6000. All four are confirmed vulnerable to bit flips under the attack, and an unprivileged CUDA program running on any of them can exploit those flips to mount either a denial-of-service attack or a privilege escalation to root on the host CPU.

The attack achieves between 72,000 and 377,000 bit flips per gigabyte of GPU memory across the four tested cards — between 4,548 and 23,597 times the bit-flip rates achieved by GPUHammer, the same research group's earlier attack from 2025. On the RTX A5000, GPUThor produces 377,000 flips per gigabyte — 23,597 times GPUHammer's rate ; on the A6000, 114,000; on the A4500, 75,000; and on the A4000, 72,000. These densities approach the rates achieved by the most aggressive CPU Rowhammer attacks on DDR4 memory.

That density shift has a direct operational consequence: the end-to-end time to find an exploitable bit flip in GPU page tables — the prerequisite for privilege escalation — drops from roughly 21.9 hours with GPUHammer patterns to approximately 1.1 minutes with GPUThor. An attack that was previously a theoretical risk requiring near-overnight persistence becomes one that can complete within a single job allocation on a shared GPU cluster.

NVIDIA's GDDR6 Ampere GPUs use SECDED ECC — a single error correction, double detection scheme that can repair one flipped bit and flag a second flip within each 16-byte protected chunk of memory. This was sufficient to stop earlier GPU Rowhammer attacks, which generated only tens to hundreds of bit flips per gigabyte — far too few to reliably overwhelm the correction code.

GPUThor achieves bit-flip densities high enough to produce errors that SECDED ECC cannot handle. When ECC was enabled on test hardware, GPUThor generated 387 double-bit errors ECC cannot correct and 2 triple-bit errors that the ECC logic silently "repaired" to the wrong value. The triple-bit finding is the critical one: SECDED ECC is designed to correct single-bit errors and detect two-bit errors, but a three-bit error within a single 16-byte chunk falls outside what the code can detect — it appears to the hardware as a single-bit error, and the correction logic produces wrong data while reporting success.

That silent misrepair matters beyond the exploits themselves. NVIDIA's advisory recommends monitoring GPU error telemetry as one defense layer — watching for anomalous spikes in ECC counter readings as a potential indicator of an attack in progress. Triple-bit errors bypass that monitoring entirely : because the ECC logic treats them as corrected single-bit errors, no counter is incremented and no alert is raised. An attack that takes this path leaves no observable trace in the monitoring systems a cloud operator would use to detect it.

To understand why prior GPU Rowhammer attacks were stopped by ECC while GPUThor is not, the key is the difference between uniform and non-uniform hammering patterns — and why non-uniform patterns, which have been used against CPU memory for years, were previously impossible to execute against GPUs.

Rowhammer works by repeatedly activating ("hammering") a DRAM memory row at high frequency, causing electromagnetic charge to bleed into neighboring rows and flip their bits. DRAM chips include an in-chip mitigation called Target Row Refresh (TRR) that samples frequently activated rows and issues corrective refreshes to their neighbors. Prior attacks evade TRR by mixing decoy rows into the hammering pattern to overwhelm the sampler — but on GPUs, a second obstacle exists: the GPU memory subsystem merges (or "coalesces") repeated accesses to the same address, collapsing many access requests into a single effective DRAM activation and nullifying most of the hammering before it reaches the chip.

The University of Toronto researchers overcame both obstacles by reverse-engineering undocumented NVIDIA Ampere GDDR6 behaviors .

First, they characterized how coalescing behaves within and across GPU thread groups (called "warps") and found that memory accesses issued from different warps targeting different cache lines of the same aggressor row survive as distinct activations rather than being merged. GPUThor's CUDA kernel distributes its repeated accesses accordingly — each warp issues at most one access to the aggressor, preventing coalescing from collapsing them.

Second, prior GPU attacks assumed that TRR on GDDR6 fires once per DRAM refresh interval (tREFI, roughly 1.9 microseconds). The researchers used bit-flip reproducibility as a side channel and discovered that TRR on Ampere GDDR6 fires once every 72 tREFIs. Hammering patterns whose length divides evenly into 72 stay synchronized with that cadence, keeping the aggressor row reliably effective while decoy rows mask it from TRR's sampler.

Together, these two discoveries allow GPUThor to sustain approximately 110,000 aggressor activations per refresh window — 6.6 times the intensity of prior uniform GPU attack patterns — while remaining undetected by TRR.

The University of Toronto researchers demonstrated two distinct attacks against ECC-enabled RTX A6000 hardware.

Denial of service. By triggering uncorrectable multi-bit errors, GPUThor causes one GPU reset every two hours , terminating every workload running on the card. If the attack is sustained, the GPU eventually exhausts its row remapping capacity for uncorrectable errors and flags itself as requiring replacement — in effect, destroying the card's service record from software alone.

Privilege escalation to root. By directing bit flips at GPU page tables, an unprivileged CUDA process gains arbitrary GPU memory access — the same class of exploit demonstrated in GPUBreach — and can open a root shell on the host CPU. This is the first time a Rowhammer exploit has achieved host-level privilege escalation on an ECC-enabled GPU. The time from starting the attack to obtaining root access is approximately 1.1 minutes.

A malicious co-tenant on a shared cloud GPU instance running this attack could steal model weights, exfiltrate training data, or use the host root shell to move laterally within the provider's infrastructure.

The researchers' confirmed findings are specific to the four Ampere workstation GPUs tested. No bit flips were observed on GDDR6X or HBM2e GPUs using the same attack patterns, indicating that different internal memory designs alter the attack surface in ways not yet characterized.

Server-class Ampere hardware, including the A100 and A800, uses the same SECDED-level ECC and remains theoretically susceptible to privilege escalation by the same mechanism — the ECC cannot handle triple-bit errors — though the risk profile varies by platform configuration. On some Blackwell-generation GPUs, RAS Repair slows the attack but does not prevent it outright. HBM3/e and GDDR7 GPUs, which include on-die ECC, may face vulnerability from multi-bit flips — but this remains an open research question the paper does not resolve.

The research also does not rule out that alternative attack patterns could trigger bit flips on GDDR6X or HBM2e; the current patterns simply were not effective against those memory types.

NVIDIA published a security advisory on August 21, 2026 — before the GPUThor paper's public disclosure on August 25. The advisory recommends enabling both SYS-ECC (system-level ECC) and IOMMU/DMA isolation, monitoring GPU error telemetry , and restricting the execution of untrusted workloads on affected hardware. NVIDIA acknowledges that risk varies by DRAM device, memory technology, platform design, and in-DRAM defenses, and notes that no bit flips were observed on GDDR6X or HBM2e GPUs using GPUThor's current attack patterns.

NVIDIA's guidance to continue enabling SYS-ECC remains valid — ECC still raises the bar and remains worth enabling. The researchers themselves make this explicit: ECC is not irrelevant, but it can no longer be considered a complete defense against this attack class .

The researchers disclosed GPUThor to NVIDIA April 29 , and also notified the major cloud providers — Google, Microsoft, and AWS — at the same time. At NVIDIA's request, the work was held under embargo until August 25, 2026. The full exploit code and artifacts are scheduled for release November 15, 2026 , timed to the opening of the CCS '26 conference in The Hague.

That release date is the operational deadline. Once the code is public, the attack becomes accessible to threat actors without the reverse-engineering and implementation work the University of Toronto researchers performed. The approximately 80-day window between now and November 15 is the period in which cloud operators running affected hardware can implement the researchers' recommendations before that work is no longer required.

The University of Toronto team is explicit that enabling ECC and adding IOMMU isolation address the symptoms but not the underlying cause. Complete mitigation needs hardware-level GPU redesign .

The researchers recommend two architectural paths. The first is stronger multi-bit error correction: upgrading from SECDED ECC to Chipkill-class ECC, which is IBM's multi-chip error scattering scheme so that any single-chip failure affects only one ECC bit per word. Chipkill-class schemes can correct errors that SECDED cannot, including the multi-bit errors GPUThor generates — but they add storage and bandwidth overhead on top of the 6.25% already consumed by SECDED in GDDR6.

The second path is adopting principled read-disturbance defenses equivalent to what CPU DDR5 memory now requires: Refresh Management (RFM) and Per-Row Activation Counting (PRAC). PRAC, standardized in JEDEC DDR5 April 2024 , adds per-row activation counters to each DRAM row; when a row's counter exceeds a threshold, an alert signal forces the memory controller to issue corrective refreshes before any attack can accumulate enough activations to trigger bit flips. GDDR6 has no equivalent of these mechanisms. GPU manufacturers would need to independently adopt PRAC-equivalent protections in future GDDR versions — a decision that GPUThor makes more urgent.

GPUThor is the third milestone from the same University of Toronto research group in just over a year — following GPUHammer (USENIX Security 2025, first GPU Rowhammer bit flips) and GPUBreach (IEEE S&P 2026, first GPU Rowhammer with IOMMU bypass). Each paper has extended the severity of what Rowhammer means for GPU infrastructure: the first showed that GPU memory is physically vulnerable, the second showed that vulnerability could reach the host operating system, and the third shows that the recommended hardware mitigation is insufficient. The CCS '26 paper represents a peer-reviewed disclosure at one of the field's four top security venues. Organizations running Ampere workstation GPUs in cloud or shared-access configurations should treat the period before November 15 as preparation time, not breathing room.

No, and this is the paper's central finding. SECDED ECC — the type deployed in NVIDIA's GDDR6 Ampere GPUs — corrects single-bit errors and detects double-bit errors, which was sufficient to stop earlier GPU Rowhammer attacks like GPUHammer. GPUThor's higher hammering intensity generates double-bit errors ECC can detect but not correct, and triple-bit errors that ECC silently "repairs" to wrong values without raising any error flag. The researchers explicitly state that ECC still raises the bar and is worth enabling — but it is no longer a complete defense, and adding IOMMU/DMA isolation is now essential alongside it.

The four confirmed affected GPUs are the RTX A4000, A4500, A5000, and A6000 — all Ampere workstation cards using GDDR6 , widely used in AI research workstations and cloud GPU instances. Consumer GeForce gaming cards do not support ECC on their GDDR6 or GDDR6X memory at all, so the ECC-defeat finding is less directly applicable — though they remain vulnerable to basic Rowhammer bit-flip attacks. Server-class Ampere GPUs like the A100 use the same SECDED-level ECC and remain theoretically susceptible to privilege escalation. No bit flips were observed on GDDR6X or HBM2e GPUs using GPUThor's current patterns.

The researchers and NVIDIA recommend a layered approach: enable both SYS-ECC and IOMMU/DMA isolation on affected hardware; avoid sharing a single physical GPU across mutually untrusted tenants wherever possible; and monitor NVIDIA ECC counters for spikes , which remain a useful signal for the double-bit errors ECC detects (though triple-bit errors bypass monitoring entirely). NVIDIA's advisory provides the vendor guidance. The November 15, 2026 public code release is the operational deadline — after that date, executing the attack no longer requires the reverse-engineering work the research team performed.

Partially. NVIDIA's advisory recommends monitoring GPU error telemetry for anomalous ECC counter spikes as an indicator of attack activity. This approach is useful for detecting the 387 double-bit errors GPUThor generates — those are logged as detected-but-uncorrectable errors. However, the triple-bit errors bypass all monitoring — silently "corrected" to wrong values by the SECDED logic, leaving no counter entry and no alert. An attacker who can reliably trigger triple-bit errors can operate below the monitoring threshold entirely.