GPU VulnDB

Database/Container, Kubernetes & orchestration

local-path-provisioner: helper pod template injection yields a privileged pod with host root mounted

CVSS 8.7CVE-2026-44543Container, Kubernetes & orchestrationcurated

Impact

local-path-provisioner is a common way to hand node-local NVMe or scratch space to pods on GPU nodes. Anyone able to edit the local-path-config ConfigMap in the local-path-storage namespace can plant securityContext.privileged, hostPath volumes and extra Linux capabilities into the helperPod.yaml template, which the provisioner then instantiates verbatim on the next PVC provision or cleanup. The result is a privileged pod with the host root filesystem mounted on the target node: host file read/write, ServiceAccount tokens belonging to other pods scheduled there, and the local-path volume data of other tenants. On a GPU node that is the whole node, including whatever training data and credentials the co-tenant workloads hold.

Who can reach it

Authenticated Kubernetes user or service account with edit rights on the local-path-config ConfigMap in the local-path-storage namespace. No node access needed - the provisioner does the privileged creation on the attacker's behalf.

What to do

Upgrade local-path-provisioner to 0.0.36 and restart the provisioner deployment; no node drain or reboot is needed. Until then, tighten RBAC so no workload identity can write that ConfigMap and audit it for injected securityContext or hostPath entries.

References

Related entries

All Container, Kubernetes & orchestration entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.