In September 2024, NVIDIA patched CVE-2024-0132, a time-of-check-time-of-use (TOCTOU) flaw in the NVIDIA Container Toolkit's mount_files routine, rated CVSS 9.0. The bug let a malicious container image escape its isolation boundary and reach the host — meaning a single poisoned model-serving image or compromised training job running on a shared, multi-tenant Kubernetes cluster could compromise every other tenant's GPU workload on that node. The patch turned out to be incomplete: in February 2025, researchers at Wiz disclosed CVE-2025-23359, a bypass of the same fix, scored 8.3. Both are only fully closed as of NVIDIA Container Toolkit version 1.17.4. Months later, in July 2025, Wiz reported a third, independent flaw — CVE-2025-23266, nicknamed "NVIDIAScape" — and estimated it affected 37% of cloud environments running NVIDIA GPUs for AI workloads. None of these are ordinary base-image CVEs. They live in the driver-and-runtime layer that mediates GPU device access, a part of the AI stack most container security programs never scan at all. This post covers the three questions that matter: how base images introduce risk, why GPU passthrough is a distinct attack surface, and what runtime policy actually stops an escape.
Why is GPU passthrough a different attack surface than a normal container escape?
Ordinary container escapes usually require a kernel bug, a misconfigured mount, or a privileged flag an attacker has to find. GPU-enabled containers introduce a new, purpose-built pathway: the NVIDIA Container Toolkit runs a hook (nvidia-container-runtime-hook) at container start that mounts host device nodes (/dev/nvidia0, /dev/nvidiactl) and host driver libraries into the container namespace so the workload can talk to the GPU. That hook runs with elevated privilege by design, on every GPU container, every time. CVE-2024-0132 exploited a race condition in how that hook resolved and mounted files — an attacker-controlled container image could win the race and get host paths mounted read-write into its own namespace. The practical consequence for AI infrastructure specifically: any team that lets user-submitted training jobs, third-party inference images, or model-serving containers request a GPU has effectively extended its trust boundary to the toolkit binary itself, not just the base OS image.
Does base-image provenance still matter if the real bug is in the GPU driver stack?
Yes — because the GPU driver and container toolkit are dependencies too, and most SBOM and CVE-scanning pipelines don't treat them that way. A typical build pipeline scans the OS packages and language dependencies baked into an image but doesn't version-pin or track nvidia-container-toolkit, libnvidia-container, or the CUDA driver bundle as tracked components. That's precisely why the toolkit sat on vulnerable versions in production clusters well after patches shipped in 2024 and 2025 — nobody's dependency inventory flagged it as a component with a CVE feed. Base-image provenance practices that already exist for ordinary containers — pinning by digest, sourcing from a hardened/attested registry, and generating a CycloneDX SBOM on every build — need to be extended to explicitly enumerate the GPU driver and container-runtime versions baked into or mounted by an AI-serving image, not just the application layer sitting on top of them.
How should teams isolate untrusted model code that needs GPU access?
Treat any container that loads externally-sourced model weights, runs a customer-submitted training job, or serves inference on unvetted input as untrusted code that happens to need a GPU, and apply the same isolation defenses used for any other multi-tenant compute: run GPU workloads without --privileged and without unnecessary Linux capabilities, enable user namespaces so a container-root UID doesn't map to host root, and where the workload profile allows it, run inference or fine-tuning jobs inside a sandboxed runtime such as gVisor or Kata Containers rather than a shared-kernel runc container. Wiz and independent researchers at Edera have each pointed to the same underlying lesson following the 2024–2025 toolkit disclosures: none of these controls stop every possible escape on their own, but they collapse a working TOCTOU-class exploit into a much narrower, much harder attack, and they limit blast radius when a new toolkit CVE inevitably surfaces.
What should runtime policy for model-serving containers actually enforce?
Runtime policy should restrict which images are even allowed to request a GPU device, not just what they can do once they have one. An admission controller that gates nvidia.com/gpu resource requests against an allow-list of signed, provenance-attested images stops an attacker from ever getting an arbitrary image scheduled onto GPU-backed nodes in the first place — closing off the toolkit's attack surface entirely for anything that isn't explicitly trusted. Beyond that gate, model-serving policy should verify the model artifact itself before it loads: check that model weights are signed and that the hash matches an attested value, and block formats like raw PyTorch pickle files that can execute arbitrary code at deserialization time unless they've been scanned and cleared. A GPU node that only ever schedules attested images running signature-verified weights has removed both halves of the exploit chain researchers have relied on since CVE-2024-0132: an attacker-controlled container, and unrestricted code execution once it's running.
How Safeguard Helps
Safeguard's Gold Registry ships SLSA-attested, signed base images with a CycloneDX SBOM per artifact, so GPU-serving images can be built from a provenance-verified starting point rather than an untracked upstream tag, and self-healing containers rebuild and redeploy an image automatically when a new CVE lands on a tracked component — typically within the 20-45 minute median time-to-heal Safeguard sees across customer tenants, which matters when a toolkit-class flaw like CVE-2025-23359 lands with a narrow patch window. On the model side, Safeguard's AI-BOM tracks model weight provenance and signing status and enforces load-time policy that blocks unsigned weights or embedded unsafe pickle code before a model-serving container ever loads them. GPU driver and container-toolkit versions specifically are an emerging tracking gap across the industry's SBOM tooling, Safeguard included — treating nvidia-container-toolkit as a first-class, CVE-tracked component alongside your OS packages is a control every team running GPU workloads should build into their inventory today, whichever platform they use to do it.