Last year Nvidia told GPU owners worried about Rowhammer to switch on error correction. Four researchers at the University of Toronto have now shown that the same attack, aimed harder, goes straight through it.
Their technique, GPUThor, is the first Rowhammer attack to defeat ECC on Nvidia GPUs. It works on four Ampere-generation workstation cards: the RTX A4000, A4500, A5000 and A6000. On each, it turns an ordinary unprivileged CUDA program into a root shell on the host computer, with error correction enabled. Chris S. Lin, Joyce Qu, Aditya Rajeev and Gururaj Saileshwar published the paper on 25 August. They will present it at ACM CCS in The Hague in November. Nvidia issued a security notice on 21 August. Bill Toulas at BleepingComputer reported the disclosure the following day; TechRadar picked it up on Monday.
The attack code stays private until 15 November. There is no patch, and the researchers say there cannot be one without new hardware.
What Rowhammer does, and why ECC was the answer
DRAM stores each bit as a charge in a cell, and the cells sit in rows packed tightly together. Hammer one row with repeated reads and charge leaks into its neighbours, flipping their bits. The attacker never touches the victim’s data directly. That is why Rowhammer has been a favourite route to sandbox escapes and privilege escalation on CPUs for a decade.
The same team brought it to GPUs. GPUHammer in 2025 produced the first bit flips in GDDR6 memory. GPUBreach earlier this year turned those flips into a root shell. Both attacks died the moment a user enabled ECC. They produced tens to hundreds of flips per gigabyte, and the GPU’s error correction could fix a single flipped bit and detect a second.
So Nvidia’s advice was correct for the attacks that existed. GPUThor is a different attack.
Hammering harder, not smarter
Earlier GPU attacks hammered uniformly, spreading effort across decoy rows to evade the chip’s built-in defence, Target Row Refresh. CPU attacks moved to non-uniform patterns years ago. Nobody had managed it on a GPU, for two reasons the paper reverse-engineers.
The first is that the GPU memory system merges repeated requests to the same address, so naive hammering collapses into a single activation. The team found that accesses from different warps to different cache lines of the same row survive as separate hits. The second is timing: Target Row Refresh on Ampere GDDR6 fires roughly once every 72 refresh intervals, not once per interval as assumed. Patterns that stay synchronised with that schedule reproduce reliably.
The result is 6.6 times the hammering intensity of prior GPU attacks, and 500 to 23,500 times more bit flips. With ECC off, the A5000 gave up 377,000 flips per gigabyte. Blacksmith, the strongest CPU attack, achieves about 550,000 on DDR4. An end-to-end privilege escalation that took 21.9 hours with GPUHammer patterns takes 1.1 minutes with GPUThor.
With ECC on, the flips arrive faster than the correction can handle. The researchers recorded 387 double-bit errors that ECC detects but cannot fix. They also saw two triple-bit errors that it silently repaired into the wrong value.
Three things an attacker can now do
The first is denial of service. On an A6000 with ECC enabled, GPUThor forces a GPU reset every two hours, killing every job on the card. Within a day the GPU declares itself defective and asks to be replaced.
The second is takeover. By corrupting GPU page tables, an unprivileged program gains read and write access to any memory and opens a root shell on the host CPU. The researchers describe it as the first such takeover on an ECC-protected GPU.
The third is silent corruption. A triple-bit error that ECC miscorrects leaves no trace. On a card training or serving a model, that is a wrong weight nobody will find.
Who should worry
The four confirmed cards are workstation parts, common in AI workstations and in cloud instances. Nvidia says no bit flips appeared on GDDR6X or HBM2e cards under the same patterns, and the researchers found none on HBM or GDDR7 either. But BleepingComputer reports the paper says privilege escalation can still work on A100 server GPUs, which use the same class of error correction. Blackwell’s repair feature slows the attack rather than stopping it, the paper says.
The setting that matters is a shared GPU. When one physical card is time-shared between users, which is common in cloud AI services, an attacker on the same card can flip bits in a victim’s data or crash the shared GPU. TNW reported in July that a cloud tenant with nothing but a rented GPU could rattle the power grid. GPUThor is the same threat model aimed at the tenant next door.
The advice, and the economics
Even an unshared GPU is exposed if it runs untrusted code, and in AI that is most of them. A model downloaded from the internet, a package pulled in by a training script, or an agent given a sandbox all run on the card. China’s Kimi K3 broke out of its sandbox at the UK’s AI Security Institute in August, and OpenAI’s agents escaped a capture-the-flag lab in July. Neither needed a hardware flaw. GPUThor hands the next one a much shorter path.
Nvidia’s own advice is to enable system ECC and IOMMU isolation together, monitor error telemetry, and restrict untrusted workloads. The researchers add: do not share a physical GPU across untrusted tenants, and treat a spike in corrected-error counts as an attack in progress.
That advice runs against the economics. The neocloud business sells shared GPU time by the hour, and short-term capacity already costs double long-term. Isolating every tenant on their own card makes it dearer still. Nvidia, which built an AI safety team this summer with a business case behind it, now has a hardware security problem with the opposite business case.
What to watch
Three things. The first is 15 November, when the code goes public on GitHub. The gap between a paper and a working exploit in the wild is usually measured from that date, not the paper’s.
The second is the A100 question. The confirmed cards are workstation parts. If the escalation path works on the server GPU that trained most of the current generation of models, the affected fleet is a different order of magnitude, and Nvidia has not said so either way.
The third is the fix that is not coming. The researchers say a complete answer needs multi-bit ECC or the DDR5-class defences, Refresh Management and Per-Row Activation Counting, built into GPU memory. Those are future products. Everything currently deployed will run with the mitigation Nvidia gave last year, which is the one this paper breaks.
You must be logged in to post a comment Login