Kevin S. Caldwell headshot
Kevin S. CaldwellCTO
STRATUM / BLOG

GPUHammer, GPUBreach, GPUThor, and the Need for a GPU Firewall

GPU memory attacks are turning the accelerator itself into a security boundary. STRATUM is building enforcement and threat-response capabilities for that boundary.

STRATUM GPU Firewall between AI workloads and isolated GPU providers, showing GPU ACLs, inspection, transport visibility, and allow or deny enforcement
STRATUM GPU Firewall inserts a STRATUM-controlled security boundary between AI workloads and GPU providers. Current enforcement begins at attachment and lease control; deeper CUDA/NVML-aware inspection and automated response are the next generation.

Modern GPUs are becoming a security boundary of their own. A GPU has device memory, page tables, virtual address translation, DMA paths, privileged driver relationships, and increasingly sensitive AI models and cryptographic material living inside its memory. The University of Toronto's GPUHammer, GPUBreach, and GPUThor research shows why that boundary deserves the same level of attention we already give networks, CPUs, storage, and operating systems.

GPUHammer demonstrated Rowhammer bit flips in the GDDR6 memory of an NVIDIA RTX A6000 using user-level CUDA code. In the researchers' proof of concept, a single bit flip could corrupt a victim model and drive accuracy from about 80 percent to 0.1 percent. GPUBreach took the next step by targeting GPU page tables. Those page tables live in GPU memory, and each page table entry, or PTE, contains the mapping between a GPU virtual address and the physical page frame behind it. Corrupt the right page-frame-number bits and the attacker's PTE can point at another page-table page. At that point, the attacker can rewrite its own address mappings and obtain arbitrary GPU memory read and write access across process boundaries.

The published GPUBreach artifact reports the GPU privilege-escalation stage at roughly 17 seconds once vulnerable bit locations have been profiled. From that arbitrary GPU read/write primitive, the researchers demonstrated cross-process memory access, leakage of secret keys from NVIDIA cuPQC, leakage of LLM weights, and code tampering inside cuBLAS. The paper also showed a path from the compromised GPU into the host CPU by corrupting trusted NVIDIA driver state inside IOMMU-permitted buffers. That driver corruption produced attacker-controlled kernel writes and a root shell even while the IOMMU remained enabled.

The disclosure history is equally notable. The University of Toronto team says it disclosed GPUBreach to NVIDIA on November 11, 2025, then to Google, AWS, and Microsoft. Google awarded a $600 bug bounty. The researchers reported that NVIDIA said it may update its existing Rowhammer security notice. NVIDIA's current public Rowhammer notice still centers its guidance on ECC and general DRAM mitigations, while the research has continued to move forward.

GPUThor is that next step. The same University of Toronto research group developed a higher-intensity, non-uniform Rowhammer technique that produced hundreds to tens of thousands of times more bit flips than earlier GPU attacks across tested RTX A4000, A4500, A5000, and A6000 GPUs. The work demonstrates multi-bit errors that can defeat the tested GPUs' system ECC protection, and on an ECC-enabled A6000 the researchers demonstrated denial of service and root-level privilege escalation through page-table corruption. ECC still raises the bar, but the tested results show that it cannot be treated as the only isolation control for shared GPU infrastructure.

This is why STRATUM is continuing to develop GPU security as a first-class infrastructure capability. The current STRATUM GPU Firewall provides real attachment-level enforcement around which workload can obtain a STRATUM GPU attachment or lease. The next generation extends that boundary toward CUDA and NVML-aware threat detection, policy enforcement, and automated response for behaviors associated with attacks such as GPUHammer and GPUBreach.

STRATUM GPU already changes the placement model by making a remote physical accelerator appear as a PCI-based GPU device inside a VM across the STRATUM Continuum. That same virtual device boundary creates an opportunity to enforce policy before a workload reaches the accelerator and to observe accelerator access through STRATUM-owned infrastructure. We believe GPU infrastructure needs firewall technology of its own. STRATUMvisor is building toward that security model directly inside the GPU fabric.

← ALL BLOG POSTS