Kubernetes NFS CSI driver flaw can let attackers delete or modify unintended directories on NFS servers

A newly disclosed vulnerability in the Kubernetes CSI Driver for NFS can let attackers delete or modify directories outside the intended managed path on an NFS server. The flaw, tracked as CVE-2026-3864, affects clusters that use the nfs.csi.k8s.io driver and allow users to create PersistentVolumes that reference it.

The bug comes from insufficient validation of the subDir parameter inside volume identifiers. According to the official Kubernetes advisory, an attacker who can create PersistentVolumes referencing the NFS CSI driver could include path traversal sequences such as ../ in crafted volume identifiers. During deletion or cleanup, the driver may then operate on directories outside the intended path within the exported NFS share.

This is not a universal Kubernetes issue. The advisory says a cluster is exposed only if three conditions line up: it runs the CSI Driver for NFS, it allows users to create PersistentVolumes that reference that driver, and it uses a version older than the fixed release. In other words, the blast radius depends heavily on RBAC, storage policy, and how your organization handles PersistentVolume creation.

Kubernetes has rated the issue Medium with a CVSS score of 6.5, but the practical impact can still be serious. If exploited, the flaw may let an attacker delete or modify directories on the NFS server that the CSI driver was never supposed to touch. That could disrupt workloads, damage shared storage, or interfere with application data outside the normal volume lifecycle.

What the Kubernetes advisory says

The official advisory is clear about the scope. All versions of the CSI Driver for NFS before v4.13.1 are affected, and the fix landed in v4.13.1. The Kubernetes Security Response Committee published the issue in the project’s official CVE feed on March 17, 2026.

The guidance also focuses on privilege boundaries. Kubernetes says untrusted users should not be allowed to create arbitrary PersistentVolumes that reference external storage drivers. That best practice matters here because the exploit path begins with the ability to define a malicious volume identifier.

CSI Driver for NFS vulnerability summary

Who is actually at risk

Organizations are at risk only when the driver is deployed and non-admin or otherwise untrusted users can create PersistentVolumes that target it. Many clusters already restrict PV creation to administrators or tightly controlled automation, which reduces the immediate exposure. Even so, teams should not assume they are safe without checking RBAC and storage workflows.

The advisory specifically warns defenders to inspect volumeHandle values for traversal sequences like ../. It also recommends reviewing CSI controller logs for suspicious directory operations, including entries that resemble Removing subPath: /tmp/mount-uuid/legitimate/../../../exports/subdir. Those are practical detection points for incident response teams.

What admins should do now

• Upgrade the CSI Driver for NFS to v4.13.1 or later.
• Restrict PersistentVolume creation privileges to trusted administrators or tightly controlled automation.
• Review existing PersistentVolumes that use nfs.csi.k8s.io and inspect volumeHandle for ../ traversal patterns.
• Audit CSI controller logs for unexpected path operations involving subDir.
• Review NFS exports and confirm the driver can write only to intended directories.
• Contact [email protected] if you find evidence of exploitation.

Why this flaw matters

Storage-layer issues in Kubernetes often get less attention than API server or ingress bugs, but they can still cause direct operational damage. In this case, the risk sits at the boundary between Kubernetes volume management and the backing NFS export. A crafted PersistentVolume definition could turn a cleanup path into an unintended delete or modify operation on server-side directories.

This is also a reminder that storage drivers inherit trust from cluster policy. Even when the bug sits in a CSI component, the ability to exploit it often depends on who can define storage resources and how much control they have over the fields those resources carry. Good RBAC and careful storage governance can sharply limit the damage from flaws like this.

FAQ