Skip to content

CVE-2026-3864: NFS CSI Driver Path Traversal Can Delete Unintended Directories

A path traversal vulnerability in the Kubernetes CSI Driver for NFS allows users with PersistentVolume creation rights to craft volume identifiers that cause the driver to delete or modify data outside its intended path on the NFS server during volume cleanup.

CVSS Score: 6.5 Medium (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:H)
Fixed in: CSI Driver for NFS v4.13.1
CVE: CVE-2026-3864

Advisory Summary

The NFS CSI driver uses a subDir field inside the volumeHandle of PersistentVolume objects to track which subdirectory within an NFS export belongs to a given volume. Before v4.13.1, that field was never validated for path traversal sequences. If you could create a PV with a volumeHandle containing ../, the driver would blindly resolve it - and when that volume was deleted, it would run directory removal operations against whatever path the traversal resolved to.

That might be a sibling tenant's data directory. It might be the export root. It depends on how many ../ hops are in the handle and what the NFS mount can reach, but the driver's mount typically spans the entire export, not just one subdirectory. There's no secondary check at deletion time. The directory just gets removed.

The vulnerability was reported by Shaul Ben Hai at SentinelOne and fixed by NFS CSI maintainers Andy Zhang and Rita Zhang with the Kubernetes Security Response Committee.

Affected Components and Versions

This is the CSI Driver for NFS (nfs.csi.k8s.io), not Kubernetes core. All versions prior to v4.13.1 are affected. The fix is purely input validation on the subDir field - no API changes, no configuration required.

You're at risk if:

  • You're running the NFS CSI driver below v4.13.1.
  • Any user, service account, or pipeline has permission to create PersistentVolumes (not just PersistentVolumeClaims) referencing the NFS driver.

The CVSS score lists PR:H (high privilege), which is technically accurate - you do need PV creation rights. But in practice, a lot of teams have granted that permission more broadly than they realize, especially to CI service accounts or namespace admins who needed storage access for automation. The score shouldn't be the reason you deprioritize this.

Why It Matters

Path traversal in a storage driver is a different class of problem than the usual CVE. There's no confidentiality impact here - this doesn't leak data. But deletion of the wrong directory on a shared NFS server can be catastrophic and immediate, and NFS is commonly used for exactly the kind of data that's hardest to recover: backups, config artifacts, shared read-write volumes across many pods.

The NFS protocol itself has no per-directory access control by default. The CSI driver is the only enforcement boundary, and it's supposed to stay within its designated subdirectory. When that breaks, the driver has implicit write/delete access to everything the mount can reach. One crafted PV deletion can affect data that belongs to completely unrelated workloads.

Worth sitting with that for a second: no exploit chain, no lateral movement, no privilege escalation needed. Just a PersistentVolume with a weird volumeHandle and a delete operation.

The fix is straightforward. Upgrade first, then do a quick audit.

  • Upgrade to CSI Driver for NFS v4.13.1 or later. Check your current version:

    kubectl -n kube-system get daemonset csi-nfs-node \
  -o jsonpath='{.spec.template.spec.containers[?(@.name=="nfs")].image}'

  • Scan existing PVs for traversal sequences in the volumeHandle. Any results here mean someone already has - or had - a crafted PV in your cluster:

    kubectl get pv -o json | jq -r '
  .items[]
  | select(.spec.csi.driver == "nfs.csi.k8s.io")
  | select(.spec.csi.volumeHandle | test("\\.\\./"))
  | .metadata.name
'

  • Audit who can create PersistentVolumes. PV creation is cluster-scoped. If service accounts or namespace-level roles have it, that's broader than it should be. Tenants should be working with StorageClasses and PVCs - the provisioner handles PV creation automatically. Direct PV creation access should belong to cluster admins only.