High
GPUThor, Rowhammer, NVIDIA, GPU Security, Privilege Escalation, Hardware
GPUThor Rowhammer Defeats ECC on NVIDIA GPUs
GPUThor is a Rowhammer attack that defeats ECC on NVIDIA GDDR6 workstation GPUs to gain a root shell. Affected cards, how it works, and how to mitigate it.
GPUThor is a new Rowhammer attack that defeats error correction codes (ECC) on NVIDIA workstation GPUs with GDDR6 memory, enabling denial of service and privilege escalation to a root shell. ECC is the very mitigation NVIDIA recommends against GPU Rowhammer, and GPUThor shows that standard ECC is not enough. Developed by researchers at the University of Toronto, the attack induced memory bit flips on four Ampere-class cards by hammering DRAM banks, and it matters most for shared and multi-tenant GPU environments, where one tenant's code can corrupt another's memory or escalate on the host.
Mounting the attack requires the ability to launch an unprivileged CUDA kernel on the target GPU, either as a co-tenant on a shared card or as untrusted code on a single-tenant machine. That precondition is exactly the situation in cloud GPU and AI training environments, where multiple workloads share hardware. GPUThor follows the same team's earlier GPUHammer, the first GPU Rowhammer attack on NVIDIA hardware, which was neutralized once ECC was enabled; what GPUThor adds is non-uniform hammering that activates the aggressor row far more often than the decoy rows, defeating the memory's Target Row Refresh (TRR) defense.
Which NVIDIA GPUs are affected?
The researchers tested four Ampere-class workstation cards with GDDR6 memory and found all of them vulnerable. NVIDIA has stated that enabling System-Level ECC mitigates the Rowhammer problem, which is the key defensive distinction: the standard ECC that GPUThor defeats is not the same as the System-Level ECC NVIDIA points to.
Item | Detail |
|---|---|
Attack | GPUThor (Rowhammer defeating ECC) |
Researchers | University of Toronto |
Affected GPUs | RTX A6000, RTX A5000, RTX A4500, RTX A4000 (GDDR6) |
Impact | Denial of service and privilege escalation to a root shell |
Precondition | Ability to run an unprivileged CUDA kernel (co-tenant or untrusted code) |
Key technique | Non-uniform hammering that defeats Target Row Refresh |
Vendor guidance | Enable System-Level ECC |
How do you defend against GPUThor?
Reduce the conditions the attack needs and watch for its symptoms. The researchers advise avoiding cross-tenant GPU sharing, monitoring ECC error counters for the bit-flip activity that precedes exploitation, and restricting untrusted CUDA workloads. Enabling System-Level ECC where available is NVIDIA's recommended mitigation, so verifying which ECC mode is actually active on your GPUs is a concrete first step rather than assuming ECC alone is protective.
Our read
GPUThor lands at an awkward moment, because shared GPU capacity is the backbone of the current AI build-out, and cross-tenant isolation on that hardware is precisely what the attack undermines. The lesson generalizes beyond one attack: a mitigation you have enabled is only as good as the version of it that is actually running, and "we have ECC" is not the same as "we have the ECC mode that stops this." For anyone renting or sharing GPU compute, the verifiable step is to confirm the specific protective mode is active and to treat untrusted co-tenant CUDA as the threat it now demonstrably is.
Reporting by The Hacker News; technical detail per the University of Toronto research and NVIDIA's security guidance. Sources linked above.
Related: AI agent security in 2026 and How to prioritize vulnerabilities.