# How Wiz found a Critical NVIDIA AI vulnerability:  Deep Dive into a container escape (CVE-2024-0132)

TOCTOU in NVIDIA Container Toolkit's libnvidia-container mount loop lets a malicious container image mount the host root filesystem and escape via docker.sock.

- Payout: Research
- Severity: critical
- Program: NVIDIA Container Toolkit
- Credited: Wiz Research
- Disclosed: 2025-02-11
- CVE: CVE-2024-0132
- Write-up quality: 9/10
- Original: https://www.wiz.io/blog/nvidia-ai-vulnerability-deep-dive-cve-2024-0132
- Library page: https://bugbountylibrary.com/r/blog%3Awiz-io-blog-nvidia-ai-vulnerability-deep-dive-cve-2024-0132
- Tags: domain:cloud domain:infra impact:internal-access impact:privesc impact:rce kind:research platform:threat-intel sev:critical tech:docker technique:chained technique:source-review vuln:path-traversal vuln:race-condition

**Target:** nvidia-container-runtime-hook / libnvidia-container prestart hook mount logic
**Root cause:** find_library_paths resolves and normalizes paths during init, but mount_files mounts them in a loop while the container filesystem is still mutable; a planted symlink destination lets an attacker swap a later source path into a symlink pointing outside the container root.
**Steps:**
1. Create image with /usr/local/cuda/compat/libnvidia-ml.so.6 as a directory and libnvidia-ml.so.7 as a regular file.
2. Plant /usr/lib64/libnvidia-ml.so.6 as a symlink pointing back to /usr/local/cuda/compat/.
3. Run container via nvidia-container-runtime; first mount_files iteration mounts libnvidia-ml.so.6 over /usr/local/cuda/compat/, replacing its contents.
4. Inside the mounted directory place libnvidia-ml.so.7 as a symlink to `../../../../../../` (host root).
5. Second iteration mounts /usr/local/cuda/compat/libnvidia-ml.so.7; kernel follows symlink and mounts host `/` at /usr/lib64/libnvidia-ml.so.7 (read-only).
6. Access host /run/docker.sock through the mounted filesystem and `docker run --privileged` to gain full host write access.
**How found:** Reviewed NVIDIA Container Toolkit source, noticed risky host-side filesystem operations during early container init before security controls apply; observed mounts of container libs onto themselves (cnt->cfg.libs_dir) and hypothesized control of mount source via symlinks; found path_resolve normalizes at init but mount_files loops over mutable paths, and xglob doesn't verify regular files.
**Exploitation:** Attacker controls the container image; the prestart hook runs on the host before security boundaries apply. The TOCTOU mount trick mounts host root read-only into the container; the attacker then talks to the host's docker.sock to spawn a privileged container, achieving full host compromise and cluster takeover in multi-tenant Kubernetes.
**Escalation:** Read-only host mount escalated to full write/RCE by abusing host docker.sock to launch a privileged container; also affects gVisor sandboxes and multi-tenant K8s clusters.
**Insight:** Prestart/OCI hooks run host-side before isolation is fully applied; look for TOCTOU where paths are resolved once at init but re-walked during a mount loop, and plant symlink mount destinations to swap later sources. Also: read-only host mounts still expose Unix sockets like docker.sock.