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.