Kubernetes GPU Node to Cluster Takeover: The Full Attack Chain
For executives
A GPU vulnerability that achieves code execution on a single Kubernetes node is not a bounded incident. Kubernetes is a distributed system where nodes are interconnected, where control plane credentials grant cluster-wide authority, and where compromising one node provides a vantage point to reach others. This article maps the complete attack chain from initial GPU container compromise through driver exploitation, credential theft, API server access, and lateral movement to adjacent nodes and the cluster control plane.
The chain in sequence
Step 1: Initial access -- container escape via Container Toolkit
The attacker gains code execution inside a GPU container via a malicious image (CVE-2025-23266), a Container Toolkit vulnerability, or a compromised application.
Step 2: Host access -- GPU driver exploitation
From inside the container, the attacker exploits a GPU driver vulnerability via crafted ioctl calls to the GPU device files. CVE-2025-23244, CVE-2026-24187, or CVE-2024-36342 (for AMD hardware) are documented paths. Kernel-mode code execution on the host results.
Step 3: Credential extraction
Every Kubernetes node runs a kubelet with a client certificate stored on the node filesystem, typically at /var/lib/kubelet/pki/. An attacker with host filesystem access can read these credentials. High-privilege service accounts mounted into infrastructure pods may also be accessible.
Step 4: API server access
With the kubelet's credentials, the attacker authenticates to the Kubernetes API server. From there, the attacker can enumerate all pods, nodes, and services in the cluster, identify additional high-privilege service accounts, and identify pods on other GPU nodes.
Step 5: Lateral movement to adjacent nodes
Authenticated to the API server with sufficient permissions, the attacker can schedule a pod on any node in the cluster. Scheduling a pod with hostPID: true and hostNetwork: true on a target node provides node-level access without requiring a further driver exploit.
Step 6: Control plane compromise
The Kubernetes control plane runs etcd, which stores all cluster state including all secrets. An attacker who reaches etcd with write access can create new service accounts, modify RBAC bindings, or inject malicious workloads.
The detection surface across the chain
Steps 1-2 are below the visibility of conventional container monitoring. Steps 3-5 produce API server audit log entries that are observable if audit logging is configured. GPU-specific telemetry provides the earliest detection signal: anomalous ioctl patterns to GPU device files precede all subsequent steps.