Malicious GPU Container Image Supply Chain: How Attackers Enter Via Compromised Base Images
For executives
Every GPU container starts from a base image. The most common is NVIDIA's own CUDA image. The majority of AI teams build their containers by layering their workload code on top of these base images. That supply chain has multiple points where a malicious actor can insert content: the base image itself, the image registry, the base image pull process, or dependencies installed during image build. A malicious GPU container image that reaches scheduling on a GPU node is the prerequisite for several of the most severe GPU security vulnerabilities documented in this library.
Why container images are a privileged delivery mechanism in GPU environments
A malicious executable that runs on a standard workstation needs to get onto the machine, gain execution, and then escalate privileges. Each step is a detection opportunity.
A malicious GPU container image that gets scheduled on a GPU node executes automatically. It gets GPU device access automatically. As CVE-2025-23266 demonstrated, a three-line Dockerfile containing LD_PRELOAD configuration achieves root code execution on the host before the container is even fully started. The escalation step is built into the vulnerability.
The base image dependency chain
Most AI containers start FROM nvidia/cuda:12.x.x-base or similar. The base image contains the CUDA runtime, driver compatibility libraries, and system utilities.
This creates a trust dependency. A registries search for nvidia/cuda on Docker Hub returns thousands of images. Many are community forks, earlier versions, or modified variants. An attacker can publish a malicious image with a convincing name and wait for teams to pull it rather than the official image.
Dependency poisoning during build
Even teams that pull official NVIDIA base images may install additional packages during image build. A compromised Python package on PyPI, a malicious apt package, or a poisoned Conda package installed during docker build can introduce malicious content into an otherwise clean container image.
The SBOM gap
SBOM tools that inventory container image contents via package manager databases miss libraries that were compiled and copied in without being registered with a package manager — a common pattern in CUDA library installation. The gap between what an SBOM reports and what is actually in a GPU container is larger than for equivalent CPU containers.
The realistic threat scenario
The most practical supply chain attack does not require compromising NVIDIA's official image registry. It requires one of: a team that pulls an outdated or community fork of an NVIDIA base image without digest verification; an automated CI/CD pipeline that pulls the latest tag of a dependency that has been compromised; or a developer who installs a typosquatted Python package from PyPI.