GPU Container Escape: How the OCI Hook Attack Pattern Produced Three Critical NVIDIA Disclosures
For executives
Container escape is the attack where code running inside a container crosses the isolation boundary to execute on the underlying host. In GPU containers, this is not a theoretical risk — it is a documented attack class with three critical NVIDIA disclosures in ten months. CVE-2024-0132, CVE-2025-23359, and CVE-2025-23266 all exploited different aspects of the OCI hook system that the NVIDIA Container Toolkit uses to configure GPU access. Understanding why OCI hooks are uniquely dangerous in GPU environments explains why the same component produced three critical vulnerabilities from the same underlying design.
What containers are supposed to do
A container uses Linux namespaces and cgroups to isolate a process from the host. The process inside the container sees a limited view of the filesystem, has its own network interface, and cannot directly access processes or files outside its namespace. The isolation is enforced by the Linux kernel.
In a CPU-only container, this isolation is robust for most threat models. GPU containers break this model at a fundamental level.
Why GPU containers are different
A GPU container needs access to GPU hardware, which lives outside the container namespace entirely. The NVIDIA GPU driver is a kernel module on the host. The CUDA libraries that workloads need are on the host. The device files are host devices. To run any GPU workload, the container needs to reach through its isolation boundary to use host resources.
The NVIDIA Container Toolkit performs this bridging. It is the component that, on every GPU container start, crosses the isolation boundary deliberately. This is not a design flaw. There is no other way to give a container access to a GPU. But every time that bridge is crossed, there is an opportunity for the crossing to go wrong in a way an attacker can exploit.
OCI hooks: the mechanism that keeps failing
The OCI specification defines a hook system that allows tools to run scripts at specific points in a container lifecycle. The NVIDIA Container Toolkit uses hooks to perform its bridging work. Hooks run at the host level and can affect the host environment.
CVE-2024-0132: the TOCTOU window
The mount_files function mounts libraries from a container image onto the host filesystem during startup. It checks that paths are safe before mounting. An attacker can replace a legitimate path with a symlink between the check and the mount. The symlink redirects the mount to a host filesystem location.
CVE-2025-23359: the bypass
The patch for CVE-2024-0132 validated paths at first resolution. CVE-2025-23359 exploits the fact that the same path is processed twice. The patch validates at first resolution but not at second use. A symlink introduced before the second resolution redirects the operation.
CVE-2025-23266: the environment variable inheritance
The createContainer hook inherited environment variables from the container image without filtering them. LD_PRELOAD, set in a Dockerfile, causes the nvidia-ctk hook — running with host root privileges — to load the attacker's library before its own code runs. Three-line exploit. No credentials. No kernel vulnerability needed.
Why the pattern keeps repeating
Each of these three vulnerabilities exploits a different mechanism. What they share: a privileged process that runs at hook time, before isolation is complete, consuming inputs from a potentially adversarial source, without adequately validating those inputs against adversarial container images.