GPUBreach: Post-Quantum Keys at Risk from GPU Rowhammer

Last updated: June 2025

Key Takeaways

• GPUBreach (arXiv:2605.03812v1) demonstrates the first GPU-side privilege escalation attack via Rowhammer bit-flips on NVIDIA GDDR-based GPUs — an unprivileged CUDA process can read or corrupt another process’s GPU memory, including cryptographic keys from cuPQC libraries
• The attack defeats IOMMU protections and chains GPU-side compromise into full CPU-side root shell access, even in single-tenant deployments
• Any organization running post-quantum cryptographic workloads on NVIDIA GPU hardware — including cloud inference, key generation, or PQC-accelerated TLS — must treat GPU memory isolation as an unverified assumption until hardware mitigations are confirmed

The Attack Scenario Your Threat Model Missed

Your organization deployed cuPQC to accelerate post-quantum key exchange on NVIDIA GPU hardware. The IOMMU is enabled. Process isolation is configured. Your security architecture review signed off on the deployment six months ago.

None of that stops GPUBreach.

A co-located workload — a containerized ML inference job, a shared cloud GPU tenant, or a compromised user-space process — runs an unprivileged CUDA kernel. That kernel hammers GDDR memory rows at high frequency, inducing targeted bit-flips in adjacent rows. Those bit-flips land in GPU page table entries. The attacker now controls which physical memory pages map to their virtual address space. They read your cuPQC private keys directly from GPU memory. Then they escalate to a root shell on the host.

This is not a theoretical attack path. Researchers published GPUBreach in May 2025, demonstrating exactly this chain from unprivileged GPU access to system-wide control.

What GPUBreach Actually Does: Technical Mechanics

Rowhammer on GDDR: Not Just a CPU Problem Anymore

Rowhammer attacks exploit a physical characteristic of DRAM: repeatedly reading from the same memory row induces electrical disturbances in adjacent rows, flipping bits without authorization. Security researchers demonstrated Rowhammer privilege escalation on CPUs years ago — but GPU memory was considered a separate, lower-risk domain.

GPUBreach closes that gap. NVIDIA GPUs using GDDR memory exhibit the same susceptibility to Rowhammer-induced bit-flips as CPU-attached DRAM. The researchers confirmed this and built a complete exploitation framework around it.

GPUBreach is defined as: a class of Rowhammer-based privilege escalation attacks targeting NVIDIA GDDR GPU memory, in which an unprivileged CUDA kernel manipulates GPU page table entries via induced bit-flips to gain unauthorized cross-process memory access, cryptographic key leakage, and CPU-side root privilege — defeating IOMMU isolation boundaries in the process.

[IMAGE: Macro-level visualization of GDDR memory cell rows with electrical disturbance patterns propagating between rows, rendered in dark tones with cyan energy arcs, no text or UI elements]

The Exploitation Chain: Four Stages to Root

Stage 1 — Memory Profiling: The attacker’s unprivileged CUDA kernel identifies exploitable DRAM row pairs by measuring access timing patterns across GPU memory. This reveals which rows are physically adjacent and susceptible to cross-row bit-flip induction.

Stage 2 — Page Table Targeting: The attack exploits GPU page table management behavior to determine when and where the GPU allocates new page tables. This is the critical innovation in GPUBreach — previous GPU Rowhammer work could only inject untargeted bit-flips into victim data (degrading ML model weights, for example). GPUBreach achieves targeted tampering of specific page table entries.

Stage 3 — Cross-Process Memory Access: With a flipped page table entry, the attacker’s process maps to physical memory pages belonging to another process. From here, the attacker reads arbitrary GPU memory — including cryptographic key material held by cuPQC library operations.

Stage 4 — CPU Privilege Escalation: GPU-side control translates to CPU-side privilege escalation. The IOMMU, which is supposed to prevent DMA-based attacks from reaching host memory, provides no protection here because the attack operates through the GPU’s own page table mechanism rather than unauthorized DMA.

“GPU-side privilege escalation can lead to CPU-side privilege escalation, defeating the protections provided by the IOMMU, enabling a malicious user-level program with GPU access to gain root shell and system-wide control, even in a non-multi-tenant setting.” — GPUBreach researchers, arXiv:2605.03812v1

cuPQC Key Leakage: The Post-Quantum Specific Risk

The researchers explicitly identify cuPQC libraries — NVIDIA’s GPU-accelerated post-quantum cryptography implementation — as a target for key extraction via GPUBreach. Organizations using GPU acceleration for PQC operations (CRYSTALS-Kyber key encapsulation, CRYSTALS-Dilithium signing, or similar NIST-standardized algorithms) face direct exposure of private key material.

This matters beyond the immediate compromise. A leaked PQC private key doesn’t just expose current sessions — it can retroactively decrypt traffic captured by adversaries running “harvest now, decrypt later” campaigns, the exact threat model that drove PQC adoption in the first place.

Comparison: Previous GPU Attacks vs. GPUBreach

Critical finding: GPUBreach is the first research to demonstrate that GPU Rowhammer attacks can achieve the same privilege escalation outcomes previously only seen in CPU-based Rowhammer exploits — and it does so while bypassing the primary hardware isolation mechanism (IOMMU) that security architects rely on.

Industry Context: Why GPU Security Assumptions Are Broken

The IOMMU Trust Problem

Enterprise security architectures treating IOMMU as a hard boundary between GPU workloads and host systems need to reassess that assumption immediately. GPUBreach demonstrates that IOMMU protection is irrelevant when the attack operates through the GPU’s internal page table mechanism. The attack doesn’t attempt unauthorized DMA — it subverts the GPU’s own memory management to achieve the same outcome.

This has direct implications for cloud GPU deployments. Major cloud providers offering GPU instances — including shared GPU pools for ML inference — have built tenant isolation partly on IOMMU guarantees. GPUBreach shows those guarantees are insufficient when untrusted code runs on the GPU itself.

Regulatory and Compliance Exposure

NIST finalized three post-quantum cryptographic standards in August 2024 (FIPS 203, FIPS 204, FIPS 205) and has set migration timelines requiring federal agencies to begin PQC adoption. Organizations accelerating PQC implementation on GPU hardware to meet these timelines may be introducing the GPUBreach attack surface at the same moment they’re trying to close the quantum threat window.

For organizations subject to FIPS 140-3 validation requirements, a cryptographic module whose key material can be extracted by an unprivileged co-tenant process fails the fundamental security boundary requirements — regardless of the algorithm’s mathematical strength.

Who Is Exposed Right Now

The attack surface is broader than multi-tenant cloud environments. GPUBreach works in single-tenant settings where multiple user-space processes share GPU access — a common configuration in:

• Enterprise ML inference servers running mixed workloads
• Development environments where PQC key generation runs alongside other GPU tasks
• Edge AI deployments with multiple containerized applications sharing a GPU
• Any system where an attacker has achieved user-level code execution and GPU access

The researchers have not published specific NVIDIA GPU model numbers or GDDR generations confirmed vulnerable, nor have they disclosed whether ECC memory configurations provide any mitigation. No CVE identifiers or NVIDIA patch timeline have been announced as of this writing. Organizations should not assume unaffected status without explicit vendor confirmation.

The BeQuantum Perspective: Hardware Trust Is Not Enough

GPUBreach illustrates a principle that shapes how we architect the BeQuantum platform: hardware isolation boundaries are necessary but not sufficient for cryptographic security. The attack doesn’t break the mathematics of post-quantum algorithms — CRYSTALS-Kyber’s lattice-based security is intact. It extracts keys before the math ever becomes relevant.

This is precisely why BeQuantum’s PQC Layer implements key lifecycle management that minimizes the window during which private key material resides in GPU-accessible memory. For organizations using our Digital Notary service for content authenticity verification, signing keys never transit GPU memory paths — they remain in isolated CPU-side secure enclaves with hardware attestation.

For deployments requiring GPU-accelerated PQC operations at scale, the IceCase hardware architecture enforces physical separation between cryptographic key storage and GPU compute memory buses. A Rowhammer attack on GDDR memory cannot reach key material that was never written there.

The broader lesson for security architects: GPU acceleration of cryptographic operations introduces a memory exposure window that CPU-side implementations don’t have in the same form. Until NVIDIA publishes hardware mitigations for GDDR Rowhammer susceptibility — and those mitigations are independently validated — GPU-accelerated PQC should be treated as a performance optimization with an attached threat model, not a drop-in replacement for CPU-side key operations.

What Your Security Team Should Do in the Next 90 Days

Step 1 — Audit GPU workload co-location within 30 days. Identify every deployment where cuPQC libraries or GPU-accelerated cryptographic operations run alongside other user-space GPU workloads. Map which processes share GPU access on each host. This inventory is your exposure baseline.

Step 2 — Isolate cryptographic GPU workloads within 60 days. Where PQC key generation or signing operations run on GPU hardware, enforce dedicated GPU allocation — no shared GPU access with untrusted workloads on the same physical device. This doesn’t eliminate the single-tenant attack vector, but it removes the most accessible co-tenant exploitation path while hardware mitigations are pending.

Step 3 — Establish a vendor response monitoring process within 90 days. Track NVIDIA’s security advisories for CVE assignments and patch releases related to GPUBreach. Evaluate whether ECC memory configurations in your GPU fleet provide any Rowhammer mitigation — contact NVIDIA directly for guidance, as the research does not confirm ECC effectiveness. Set a decision checkpoint: if no hardware mitigation is available within six months, evaluate migrating PQC key operations to CPU-side secure enclaves or dedicated HSMs.

Frequently Asked Questions

Q: Does GPUBreach require physical access to the target system? A: No. The attack is executed by an unprivileged user-space CUDA kernel — software running on the GPU without elevated permissions. An attacker needs only the ability to run GPU code on the same physical device as the victim process, which is the standard access model for shared GPU environments, cloud GPU instances, and multi-process GPU servers.

Q: If my organization uses CRYSTALS-Kyber or CRYSTALS-Dilithium via cuPQC, are the algorithms themselves broken? A: The post-quantum algorithms are mathematically unaffected. GPUBreach attacks the implementation environment, not the cryptographic primitives. The attack extracts key material from GPU memory before or during cryptographic operations — the same way a memory scraping attack on a CPU would steal keys without breaking RSA. Migrating to stronger algorithms does not close this vulnerability; isolating key material from GPU memory does.

Q: Does enabling IOMMU on the host system prevent GPUBreach? A: No. The researchers explicitly demonstrate that GPUBreach defeats IOMMU protections. The attack operates through the GPU’s internal page table management mechanism rather than through DMA channels that IOMMU monitors. IOMMU remains valuable for other threat vectors but provides no defense against this specific attack chain.

Source: GPUBreach: Privilege Escalation Attacks on GPUs using Rowhammer, arXiv:2605.03812v1