Skip to main content

GPU Compute Hijacking in Kubernetes: Stealing Capacity at Scale Without Triggering Detections

For executives

GPU compute hijacking is the large-scale version of container-based cryptomining: stealing not just a single GPU but an organisation's entire GPU cluster capacity, or as much of it as the attacker can reach. In Kubernetes-managed GPU environments, several distinct paths exist to acquire unauthorised GPU access — from scheduler misconfigurations to the Device Plugin API bypass documented in CVE-2024-0135.

The Kubernetes GPU scheduling model and its gaps

Kubernetes manages GPU resources through the device plugin framework. A pod requests GPUs via resource limits, the scheduler assigns the pod to a node with available GPU capacity, and the device plugin allocates specific GPU device files to that pod. In theory, a pod that does not request a GPU does not get one.

CVE-2024-0135 demonstrated that the default GPU Operator installation allowed unprivileged containers to bypass this entire model by setting NVIDIA_VISIBLE_DEVICES=all in their pod specification. A pod that requested zero GPUs could access all GPUs on the node. This bypass has been patched, but it illustrates the architectural gap.

Scheduler abuse without exploiting CVEs

Not all GPU compute hijacking requires a CVE. Permissive RBAC that allows pod creation in a namespace without GPU resource quotas lets an attacker request GPUs freely. Cluster-admin service accounts mounted into pods give an attacker the ability to modify resource quotas or delete legitimate pods to free GPU capacity.

The economics at scale

At the scale of an enterprise AI cluster, the financial value of unauthorised GPU access is substantial. At $8-30 per GPU-hour market rate, hijacking 100 GPUs for 24 hours represents $19,200 to $72,000 in stolen compute. Detection based on utilisation metrics alone does not catch the attacker. Kubernetes resource metrics show GPU capacity consumed but not by what workload.

Kubernetes-level monitoring and its limits

Kubernetes monitoring tools observe pod scheduling, resource requests, namespace-level metrics, and API audit logs. What they do not observe: what code is actually executing on the GPU inside a pod, whether the CUDA workloads declared by the pod spec match actual GPU computation, or whether a pod that declared no GPU request is accessing GPU hardware.