NVIDIA Container Toolkit Security: CDI and CVE Hardening

Why the toolkit is a high-value target

The NVIDIA Container Toolkit runs privileged code on the host every time a GPU container starts. Its job is to put device nodes, driver libraries and symlinks into a filesystem that the container image controls. That code runs as host root while the image may come from a tenant. Every serious toolkit CVE since 2024 exploits this: a crafted image wins a race, plants a symlink, or gets its library loaded into a host-side hook, and gains host filesystem access or root code execution. On a shared node, that means every other tenant's models and data.

Short version for October 2026: run toolkit 1.19.1 or later and GPU Operator 26.3.2 or later. Those are the fixed versions for the most recent advisory, CVE-2026-24260 ^[1]. The current release is v1.20.1, published 2026-09-19 ^[2], and NVIDIA's 2026 CVE index lists no newer toolkit or GPU Operator bulletin as of 2026-10-28 ^[3]. Use CDI or JIT-CDI mode, but don't treat CDI as a security fix. The critical 2025 bug, NVIDIAScape, was exploitable only in CDI mode on toolkit versions before 1.17.5. Track NVIDIA's bulletins rather than release notes, and keep untrusted images off nodes that host sensitive workloads.

For sharing and isolation performance rather than runtime security, see MIG, MPS and time-slicing on Kubernetes.

How the toolkit touches a container: legacy, CDI and JIT-CDI

The toolkit can inject GPUs into a container in three ways. Each one runs a different set of host-side code.

Legacy mode. nvidia-container-runtime wraps runc. It adds the NVIDIA Container Runtime Hook to the incoming OCI spec, and that hook calls nvidia-container-cli (libnvidia-container) to mount driver files into the container's root filesystem. The library inspects and modifies a rootfs that came from the image, so it is exposed to time-of-check/time-of-use (TOCTOU) and symlink tricks.

CDI mode. The Container Device Interface (CDI) is "an open specification for container runtimes that abstracts what access to a device, such as an NVIDIA GPU, means" ^[4]. A CDI spec on the host lists the device nodes, mounts and hooks for each device, and the runtime applies the spec. NVIDIA's docs say that in CDI mode "the NVIDIA Container Runtime does not inject the NVIDIA Container Runtime Hook" into the OCI spec. CDI does not remove hooks altogether. NVIDIA's generated specs still contain small hooks run by nvidia-ctk/nvidia-cdi-hook, such as update-ldcache, create-symlinks and enable-cuda-compat ^[2].

JIT-CDI mode. Since v1.18.0 (2025-10-21), the runtime defaults to "a just-in-time-generated CDI specification instead of defaulting to the legacy mode" ^[2]. With mode = "auto", the runtime picks JIT-CDI on systems that use NVML, and it "does not write a persistent specification" to /var/run/cdi or /etc/cdi ^[4]. NVIDIA's release notes say legacy mode is deprecated but still supported ^[5].

A fleet that was installed before October 2025 and never reconfigured may therefore run a different mode on each node. Upgrades alone can change which code path a node uses.

The advisory record, 2024 to 2026

All rows come from NVIDIA's own bulletins, read from NVIDIA's GitHub mirror of its PSIRT bulletins because the nvidia.custhelp.com pages returned HTTP 403 on 2026-10-28. Scores are NVIDIA's CVSS v3.1 base scores.

Sources: bulletin 5582, bulletin 5616, bulletin 5659, bulletin 5850. Smaller fixes in the same period include CVE-2024-0134 (symlink escape, fixed in 1.17.0) and CVE-2024-0135/0136/0137, which the release notes list under 1.17.3 ^[5].

Scores can differ by scorer. NVD rescored CVE-2024-0132 at 8.3 High (AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H), while NVIDIA scored it 9.0 ^[6]. NVD has published no score of its own for CVE-2025-23266 (status Deferred) or CVE-2026-24260 (Awaiting Analysis) as of 2026-10-28, so only NVIDIA's scores exist for those two. Bulletin 5850 has not been revised and still gives no technical detail. If your SLA keys off scores, record which scorer you use.

CVE-2024-0132 and the legacy-path TOCTOU family

NVIDIA describes CVE-2024-0132 as a TOCTOU flaw "when used with default configuration where a specifically crafted container image may gain access to the host file system" ^[7]. The toolkit checks a path inside the image's rootfs, then acts on it; a crafted image swaps what the path points to in between. NVIDIA lists code execution, privilege escalation, data tampering and information disclosure as impacts.

CVE-2025-23359, published five months later, has nearly the same description and the same CVSS vector. It affected everything up to 1.17.3 ^[8]. Patching one legacy-path TOCTOU did not close the class. Both bulletins state that the bug "does not impact use cases where CDI is used." The strong argument for CDI comes from this family: the large libnvidia-container code path that mounts into an image-controlled rootfs is no longer in the loop.

CVE-2025-23266 (NVIDIAScape): a hook bug on the CDI path

Wiz Research disclosed NVIDIAScape on 2025-07-17 ^[9]. As Wiz describes it, the toolkit registers an OCI createContainer hook that runs /usr/bin/nvidia-ctk with enable-cuda-compat. That hook "runs as a privileged process on the host". createContainer hooks "inherit environment variables from the container image unless explicitly configured not to", and the hook runs "with its working directory set to the container's root filesystem." Put together, an image can set LD_PRELOAD and get its own shared library loaded into the privileged hook. Wiz's proof of concept is three lines:

FROM busybox
ENV LD_PRELOAD=/proc/self/cwd/poc.so
ADD poc.so /

NVIDIA's bulletin gives the affected range as "All versions up to and including 1.17.7 (CDI mode only for versions prior to 1.17.5)". The fixed versions are toolkit 1.17.8, GPU Operator 25.3.2, Kubernetes Device Plugin 0.17.3 and MIG Manager 0.12.2. The device plugin was affected "only when device-list-strategy is cdi-annotations and/or cdi-cri", and MIG Manager "only when CDI is enabled" ^[10]. For GPU Operator, the bulletin (revision 2.0.0, 2025-08-12) and NVIDIA's CVE index list versions up to and including 25.3.1 as affected, while the CVE.org record still says 25.3.0; we follow NVIDIA's bulletin.

Read the parenthetical carefully, because it is often read backwards. It does not say CDI was safe. It says that before 1.17.5, only CDI mode was vulnerable, because CDI specs were the path that ran nvidia-ctk hooks as createContainer hooks. Version 1.17.5 added a dedicated enable-cuda-compat hook for CUDA forward compatibility ^[2]. The bulletin's range implies that from 1.17.5 through 1.17.7, legacy-mode nodes were exposed as well. The bulletin also says CVE-2025-23266 "does not affect systems where crun is used as the low-level runtime".

The fix is not described as a security fix in the release notes. The v1.17.8 notes call it a bugfix release ^[5]. The v1.17.7...v1.17.8 diff includes a commit merged from a private fork, titled "Add NVIDIA_CTK_DEBUG=false to hook envs" ^[11]. Our reading, which NVIDIA has not confirmed: giving the hook an explicit environment stops it from inheriting the image's environment, which is the condition Wiz described. The upstream end-to-end tests now build an nvidiascape-test image with ENV LD_PRELOAD=/proc/self/cwd/poc.so as a regression check ^[12].

Interim mitigation if you cannot upgrade yet (per Wiz). Disable the hook in /etc/nvidia-container-toolkit/config.toml:

[features]
disable-cuda-compat-lib-hook = true

On GPU Operator, Wiz gives these Helm values:

--set "toolkit.env[0].name=NVIDIA_CONTAINER_TOOLKIT_OPT_IN_FEATURES" \
--set "toolkit.env[0].value=disable-cuda-compat-lib-hook"

For Operator versions before 25.3.1, Wiz suggests pinning toolkit.version=v1.17.8-ubuntu20.04 (or v1.17.8-ubi8 on RHEL/OpenShift). The flag itself was introduced in v1.17.5 ^[2]. Turning it off removes CUDA forward-compatibility library injection, which affects containers that rely on a newer CUDA than the host driver; see the CUDA compatibility upgrade gate before you flip it fleet-wide.

What CDI buys you, and what it doesn't

CDI is a smaller, more auditable attack surface, not the removal of privileged code from container start. Keep patching on bulletin cadence in any mode.

Patch process

1. Inventory per node, not per cluster. Record the toolkit package version, the runtime mode, the low-level runtime (runc or crun) and, if you use it, the GPU Operator chart version. On a host, nvidia-ctk --version and the package manager give the toolkit version; helm list -A gives the Operator chart. For multi-component upgrades, see the GPU Operator upgrade gate.

2. Subscribe to bulletins, not release notes. Fixed versions have shipped before the bulletins that name them:

Release dates are from GitHub releases; bulletin dates are from bulletins 5616, 5659 and 5850. Worked example for 1.17.8: 1 remaining day of May + 30 days of June + 15 days of July = 46 days. Neither the 1.17.8 nor the 1.19.1 release notes name the CVE they fixed. Teams that upgrade only on CVE announcements sat on vulnerable versions for those weeks; teams tracking releases were already patched. Because the upstream repo lists no GitHub security advisories after the 2024 pair, use NVIDIA's bulletin repository as the feed.

3. Canary, then roll. Toolkit upgrades can change mode defaults, compat libraries and injected files. Canary one node per GPU and driver combination with a CUDA smoke test and an LD_PRELOAD negative test like the upstream e2e test, then drain and roll.

4. Keep a rollback, but pin forward. Roll back only to a version that is not in a known-affected range. As of 2026-10-28 that means nothing below 1.19.1.

Hardening checklist

• Patch level: toolkit ≥ 1.19.1 and Operator ≥ 26.3.2 ^[1].
• Mode: CDI or JIT-CDI everywhere. NVIDIA warns CDI "can conflict with" a leftover legacy hook at /usr/share/containers/oci/hooks.d/oci-nvidia-hook.json; delete it ^[4].
• Compat hook: if you don't use CUDA forward compatibility, set disable-cuda-compat-lib-hook = true as defense in depth, even on patched versions.
• Image environment, not just pod spec: the NVIDIAScape vector was an ENV line in the image. Admission policies that check only pod.spec.containers[].env would not have seen it. Scan the image config for LD_PRELOAD, LD_LIBRARY_PATH and similar loader variables at the registry or admission layer.
• Untrusted images: run tenant-supplied images only on nodes that hold no other tenant's data. Wiz's own conclusion was that "containers are not a strong security barrier and should not be relied upon as the sole means of isolation" ^[9]. For hostile multi-tenancy, use a VM boundary per tenant; see confidential GPU attestation for the strongest version of that.
• Capabilities: deny CAP_SYS_ADMIN to tenant pods. Since v1.20.1, a container with CAP_SYS_ADMIN that sets NVIDIA_MIG_CONFIG_DEVICES or NVIDIA_MIG_MONITOR_DEVICES to all gets /dev/nvidia-caps MIG management nodes injected ^[2].
• Pod security: enforce non-root, no privileged pods, read-only root filesystem where the workload allows. These limit what a compromised container can do, though a hook-level escape runs as host root before the workload process starts.

MIG is not an escape boundary

MIG partitions GPU hardware: "Each GPU slice includes dedicated GPU memory resources", a GPU instance "provides memory QoS", and MIG supports up to 7 partitions per GPU, compared with 48 MPS clients. Within a GPU instance, though, "The CIs share memory and engines" ^[13]. That is isolation between GPU workloads; it does nothing about a toolkit hook running on the host CPU. Seven tenants on seven MIG slices share one toolkit, one runc and one kernel, so one NVIDIAScape image would have compromised all seven.

Detection and auditing

• Spec drift: nvidia-ctk cdi list shows the CDI devices in use. nvidia-ctk --debug cdi list reports errors from loading specs in /etc/cdi or /var/run/cdi ^[4]. Hash static specs and alert when a spec changes outside a maintenance window.
• Hook process lineage: alert on nvidia-ctk or nvidia-cdi-hook processes that open files outside driver and library paths, spawn shells, or make network connections.
• Image provenance: require signed images from approved registries for GPU namespaces, and keep the loader-variable scan above in the pipeline.
• Retrospective hunt: for any period when nodes ran ≤ 1.17.7, search registry and pull logs for images whose config sets LD_PRELOAD.

CDI operations

Since v1.18.0, the nvidia-cdi-refresh service generates /var/run/cdi/nvidia.yaml when the toolkit or driver is installed or upgraded and at reboot. To generate the spec by hand:

sudo nvidia-ctk cdi generate --output=/var/run/cdi/nvidia.yaml
nvidia-ctk cdi list

According to NVIDIA's docs, the spec must be regenerated manually after removing drivers or reconfiguring MIG ^[4]. Include that step in MIG reprofiling runbooks. A stale spec breaks workloads and is an unreviewed change to what containers can reach.

Hardening runbook

GPU Smith helps teams scope this kind of runtime hardening alongside GPU sizing and deployment.