k8s-device-plugin Image Supply Chain: The Rolling Base OS CVE Problem in NVIDIA's Own Kubernetes Plugin
For executives
The NVIDIA Kubernetes Device Plugin (k8s-device-plugin) is the Kubernetes component that manages GPU resource allocation and scheduling. Every Kubernetes cluster running GPU workloads has it installed. The plugin ships as a container image, and that image — across multiple minor releases in 2025 — carried a persistent inventory of medium-severity CVEs in its base OS packages: glibc, gnutls, systemd-libs, libarchive, and similar system libraries. NVIDIA does not patch these OS package CVEs between minor releases. The GitHub issues log from the NVIDIA k8s-device-plugin repository documents users repeatedly reporting these vulnerabilities and receiving no fix. A plugin that runs with elevated Kubernetes privileges and carries unpatched OS vulnerabilities is a supply chain risk to every GPU cluster it is installed on.
What the k8s-device-plugin does and where it runs
The k8s-device-plugin is a DaemonSet that runs on every GPU node in a Kubernetes cluster. Its role: advertise GPU resources to the Kubernetes scheduler, allocate specific GPU device files to pods that request them, and manage the device plugin API that enforces GPU resource limits.
As a DaemonSet, it runs with elevated privileges — it needs to access GPU device files, communicate with the kubelet, and modify node annotations. It runs continuously on every GPU node.
The OS package CVE accumulation
NVIDIA ships the k8s-device-plugin as a container image built on Red Hat UBI9 (and ubuntu variants). The base OS packages — glibc, gnutls, systemd-libs, libarchive, curl, krb5-libs — carry their own CVE histories that are patched on new base OS releases but not always updated promptly in NVIDIA's plugin image.
The GitHub issue tracker for the NVIDIA k8s-device-plugin repository documents this pattern:
Issue #1256 (May 2025): k8s-device-plugin v0.17.1-ubi9 carries a vulnerable kubelet version per CVE-2024-904. Marked stale by automated tooling.
Issue #1288 (June 2025): k8s-device-plugin v0.17.2 on RHEL9 carries CVE-2025-4373 (glib2), CVE-2024-52533 (glib2), CVE-2025-4802 (glibc), CVE-2024-12243 (gnutls), CVE-2025-24528 (krb5-libs), CVE-2023-30571 (libarchive), CVE-2025-25724 (libarchive), CVE-2024-12133 (gnutls), and more.
Issue #1384 (August 2025): k8s-device-plugin v0.17.3 on RHEL9 carries a further set of unpatched CVEs in the same package families.
The pattern: each new minor release carries OS package vulnerabilities that were present in the previous release and have not been addressed.
Why unpatched OS CVEs in a privileged DaemonSet matter
The OS packages in a container are not necessarily exploitable just because they carry CVEs. The exploitability depends on whether the vulnerable code path is reachable given the plugin's actual execution context.
But a DaemonSet running with elevated privileges on every GPU node is a particularly high-value target. glibc vulnerabilities that enable local privilege escalation or information disclosure are directly relevant in a process that runs with the privileges the k8s-device-plugin operates at. A supply chain attacker who can introduce a malicious update to one of the affected packages — via a compromised package repository — reaches the k8s-device-plugin and through it every GPU node in the cluster.
What this means for GPU infrastructure security teams
Monitor the k8s-device-plugin version and the CVE status of its component packages as a distinct activity from monitoring GPU driver and Container Toolkit versions. The plugin image should be treated as infrastructure software with its own patch cadence, not as a stable platform component that only updates with major version changes.
Consider pinning specific plugin image digests in production and explicitly reviewing the CVE status of each new version before deploying it.