What OCI Hooks Are: And Why They Became a Recurring GPU Vulnerability Class
For executives
OCI hooks are the mechanism at the centre of the Container Toolkit vulnerability series. CVE-2024-0132, CVE-2025-23267, and CVE-2025-23266 all exploit different aspects of how the NVIDIA Container Toolkit uses OCI hooks. Understanding what hooks are, why they exist, and what makes them dangerous in GPU environments explains why three critical vulnerabilities emerged from the same design pattern in less than a year.
The Open Container Initiative
The Open Container Initiative (OCI) is a standards body that defines specifications for container formats and runtimes. The OCI Runtime Specification defines how container runtimes should create, start, and delete containers. It is what makes containers portable across different runtimes (Docker, containerd, CRI-O).
What hooks are
The OCI Runtime Specification includes a hook system. Hooks are external programs that a container runtime runs at specific points in a container's lifecycle:
Prestart hooks: run after the container's namespace is created but before the container's process starts. The hook runs in the host's mount namespace, not the container's.
CreateRuntime hooks: run after the container's namespaces are set up but before the container's filesystem isolation is established.
CreateContainer hooks: run after the container specification is created but before the container's execution environment is fully established. Crucially: hooks that run before pivot_root execute in a context where the host and container filesystems are not yet fully separated.
Why GPU containers use hooks
GPU hardware lives on the host. Before a GPU container can use a GPU, the Container Toolkit needs to configure which GPU devices the container can access, mount GPU driver libraries from the host into the container, and set up the CUDA compatibility layer. All of these require accessing host resources from the container's setup context — which means they must happen before the container's isolation is complete.
Why the design creates a recurring vulnerability surface
The hooks run as privileged processes on the host. They receive input from the container specification — environment variables (the LD_PRELOAD vector in CVE-2025-23266), filesystem paths (the mount operation vector in CVE-2024-0132), and hook configurations.
That input comes from the container image — which is, in the threat model, potentially attacker-controlled. If the hooks process that input without adequately validating it against adversarial cases, the attacker can influence what the privileged hook process does on the host.
Three separate aspects of hook input handling produced three critical CVEs:
CVE-2024-0132: the prestart hook's mount operation was vulnerable to TOCTOU — an attacker could replace a validated path with a symlink between check and use.
CVE-2025-23267: the update-ldcache hook followed symlinks in paths it processed without verifying they resolved within the container boundary.
CVE-2025-23266: the createContainer hook inherited environment variables from the container image including LD_PRELOAD, allowing library injection into the hook process.
The underlying tension — privileged hooks that must consume container-image inputs — remains. Future vulnerabilities in the hook system are plausible as researchers continue examining the Container Toolkit's hook implementations systematically.