GPU Driver Exploit to Node Compromise: From Container to Cluster Owner
For executives
When an attacker exploits a vulnerability in the NVIDIA GPU driver from inside a container, they are not just compromising that container. The GPU driver runs as a kernel module on the host. Kernel-level code execution gives the attacker complete control of the physical node — every container running on it, every GPU's memory, every network connection from that machine. From a compromised node, reaching the Kubernetes control plane, adjacent nodes, and the broader cluster network is the next step. This article traces the full chain.
The starting position
The attacker starts inside a GPU container with whatever access the container's process has — typically a non-root user running an AI workload, with access to the GPU via device files.
Step one: exploiting the GPU driver
Every CUDA operation ultimately translates to an ioctl call against a device file (/dev/nvidia0, /dev/nvidiactl, etc.) that the kernel module handles. A driver vulnerability in this path executes in the kernel context of the host.
The October 2025 bulletin contained use-after-free and race condition vulnerabilities in the NVIDIA Linux display driver. The January 2025 bulletin contained buffer overflows in the kernel driver layer. The AMD Instinct line carries its own heap overflow in the kernel-mode driver. Any of these, exploited from a GPU container with access to the device files, produces kernel-level code execution on the host.
Step two: establishing host access
With kernel-level execution, the attacker can read and write any memory on the host, mount the host's root filesystem, read the container runtime configuration for all running containers, and extract secrets from other processes' memory.
Every node runs a kubelet process that communicates with the Kubernetes API server. The kubelet's credentials are stored on the node's filesystem. An attacker with host filesystem access can read those credentials.
Step three: reaching the Kubernetes API
With stolen kubelet credentials, the attacker can authenticate to the API server. From the compromised node, the attacker can access the pod CIDR and service network. Service accounts mounted into other pods may have cluster-admin privileges or access to sensitive resources.
Step four: lateral movement to adjacent nodes
From a compromised node with API server access, the attacker can schedule workloads on other nodes. Alternatively, from the host network of the compromised node, the attacker can reach management interfaces of adjacent nodes.
The detection gap
Conventional runtime security monitors container process behaviour via eBPF probes on syscalls. Kernel-level code execution from a driver exploit does not look like container process behaviour. GPU-specific telemetry — monitoring ioctl patterns to the GPU device files, observing unexpected GPU kernel launches — provides earlier signal.