Kubernetes Storage Flaws Expose a Dangerous Security Blind Spot

Why the Kubernetes Vulnerability Was Only the Symptom 

The vulnerabilities, CVE-2026-3864 and CVE-2026-3865, were discovered in the Kubernetes CSI drivers for NFS and SMB, respectively. Here the emphasis isn't on the specific bugs that allow manipulated volumeHandle values to escape the designated storage subdirectory of the volume and into the wider filesystem, allowing cross-tenant file access and possibly destructive filesystem operations in some NFS controller configurations.

The software worked exactly as designed in many places. The design assumptions failed. The real architecture failure happened long before any filesystem call was made.

Where the Security Boundary Actually Broke

Consider the lifecycle of a storage request in a modern cluster. An authorized user or service account creates a PersistentVolume manifest containing a driver-specific configuration value inside the volumeHandle.

The Kubernetes API server receives the object. It authenticates the user, evaluates RBAC rules, and authorizes the creation. Everything so far is completely standard. The API server has verified who submitted the request and whether they are permitted to create storage objects.

Then, the privileged CSI driver picks up the configuration. It extracts the volumeHandle, passes it to standard path manipulation utilities like filepath.Join(), and executes a mount, read, or delete operation on the underlying host or tenant filesystem.

In the affected request path, no layer independently verified that the resulting filesystem path remained inside its intended boundary. Kubernetes treated volumeHandle as opaque and delegated its interpretation and validation to the CSI driver. The driver behaved as though values accepted by the API server did not require an independent containment check. Meanwhile, automation tooling assumed Kubernetes had already intercepted anything dangerous.

Every single component technically performed its assigned responsibility according to its local context. The design assumption itself was what failed.

Authorization Is Not the Same Thing as Validation

In many enterprise environments, security reviews grind to a halt the moment authentication and authorization pass. If an identity has the right role binding, the request is treated as legitimate.

This creates a blind spot across modern pipelines, whether in API gateways, CI/CD pipelines, GitOps controllers, or privileged Kubernetes operators.

When configurations flow from Git repositories through GitOps operators directly into the Kubernetes API, organizations frequently treat the entire pipeline as a trusted conduit. If the deployment manifest is signed or committed by an authorized engineer, the contents of that manifest are implicitly trusted.

This highlights the delicate balance of distributed systems. Delegated validation is necessary for performance and automation; blind trust without explicit verification is what turns an authorized API call into an unmitigated attack vector. Every validation layer introduces complexity and performance trade-offs. The goal is not to validate everything everywhere, but to identify the points where privileged components transform externally supplied data into high-impact operations. As outlined in the Kubernetes authentication and authorization model, access control mechanisms are designed to gatekeep entry, not to inspect the semantic safety of internal data structures.

The Same Trust Assumption Has Appeared Repeatedly Across Infrastructure

If this were an isolated incident confined to a single storage driver, it would simply be a patch-and-forget bug. But when researchers repeatedly uncover related trust-boundary failures across different infrastructure layers, the underlying pattern demands attention.

The historical evidence shows that whenever a privileged component assumes that upstream input is safe, containment eventually fails:

• Nimbuspwn: Relied on filesystem state remaining trustworthy between validation and execution.
• runC: Assumed a normalized path syntax guaranteed a contained physical destination (GHSA-c3xm-pvg7-gh7r).
• Leaky Vessels: Lost track of context boundaries when handling untrusted configurations across namespaces.

The root cause is seldom broken authentication. Such cases are a strong manifestation of the classic confused deputy problem in which a privileged component uses its authority on behalf of a less-trusted requester without independently confirming that the request target is appropriate.

Although these vulnerabilities occurred in different projects, at different times, and were researched by different people, they all followed the same progression. A less-trusted layer provided input, a privileged component inherited that trust, and no independent validation occurred to ensure that the operation was still within its intended boundary. 

Why This Architectural Pattern Keeps Recurring

Modern Linux stacks are rarely monolithic. A typical production environment combines Kubernetes orchestrators, CSI storage plugins, CNI networking plugins, GitOps agents, custom operators, container runtimes, Linux kernel namespaces, SELinux/AppArmor profiles, and cloud-native storage APIs.

One reason these issues continue appearing is that modern infrastructure increasingly treats configuration as trusted data rather than untrusted input. Kubernetes manifests, GitOps repositories, Helm charts, Terraform state, and storage definitions often move through privileged systems with little semantic validation because they are perceived as infrastructure definitions rather than user input.

Because responsibilities are so heavily fragmented, no single component ultimately owns the end-to-end validation of semantic data like file paths or storage handles:

• Kubernetes assumes storage drivers validate storage-specific values.
• Storage drivers assume Kubernetes already filtered dangerous input.
• Automation assumes both layers performed sufficient validation.
• Developers assume helper functions enforce containment.

When every component in a pipeline assumes someone else already validated the request, security boundaries dissolve. Developers may rely on utilities such as filepath.Join(), which cleans and combines path elements. However, security teams must remember a critical operational rule:

Meanwhile, platform teams may deploy admission controls that validate schemas, approved resources, and common policy violations without inspecting the driver-specific meaning of opaque values such as volumeHandle.

To bridge this gap, teams must look toward enforcement mechanisms such as Kubernetes admission control and request validation or declarative constraints using ValidatingAdmissionPolicy to catch dangerous values before they ever hit privileged controllers.

Why Organizations Keep Missing Architectural Risk

Organizations have never invested more in detection engineering. So why do trust-boundary failures continue surfacing across modern infrastructure?

While engineering teams struggle with fragmented ownership, leadership and governance structures often drive organizations to look the other way. Organizations continue investing heavily in detection coverage, SOC visibility, response automation, and threat hunting. These metrics are easy to count: alerts handled, coverage percentages, and response times. Architecture is harder to measure. It requires tracing how trusted data moves between APIs, controllers, runtimes, and privileged Linux processes.

Consequently, security programs prioritize patch management and reactive detection over proactive structural analysis. But as security leaders know, detection is a compensating control, while validation is a preventive control. SIEMs, EDR agents, and runtime telemetry cannot reliably compensate for privileged software making unsafe decisions. Because the API request and the privileged process are both authorized, the resulting activity may initially resemble legitimate controller behavior. Detection observes the consequences of a boundary failure rather than preventing the boundary from being crossed.

Building truly resilient systems requires adhering to foundational principles like Saltzer and Schroeder's secure design principles, particularly the principle of complete mediation, alongside implementing robust secure path resolution techniques for privileged applications that actively verify boundaries rather than trusting input strings.

What Security Leaders Should Audit Instead of Simply Patching

Applying the latest vendor patches (such as upgrading the Kubernetes NFS CSI Driver to v4.13.1+ and the SMB CSI Driver to v1.20.1+) closes the disclosed vulnerabilities, but it does not address the same trust assumption elsewhere in the infrastructure. True risk reduction requires shifting attention away from individual CVEs and toward systemic trust boundaries by executing targeted administrative audits: 

• Audit high-privilege storage creation permissions across all namespaces to see who can instantiate raw storage assets:

kubectl get clusterrolebindings -o json | jq '.items[] | select(.roleRef.name | test("storage|admin|cluster-admin"))'

• Verify overly permissive cluster-wide access to create PersistentVolumes or modify driver configurations:

kubectl auth can-i create persistentvolumes --all-namespaces

• Inspect active admission constraints to ensure custom path-validation policies are enforced before requests hit storage controllers:

kubectl get validatingadmissionpolicies

• Review service accounts tied to GitOps controllers and automation pipelines to verify they do not possess excessive cluster-admin privileges:

kubectl get sa --all-namespaces

• Audit host-mounted storage configurations and privileged daemonsets to confirm restricted root filesystem access:

kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.volumes[*].hostP

The Next Trust Boundary Is Already Here

The larger lesson extends well beyond Kubernetes storage. As enterprise infrastructure continues to scale, systems are becoming increasingly modular. Every new abstraction—whether driven by microservices, GitOps, or emerging AI-driven automation agents—introduces another trust boundary where configuration morphs into execution.

As automation accelerates, explicit validation becomes more critical, not less. The next major infrastructure vulnerability probably won't come from a completely new mistake. It will come from another trust boundary that nobody realized they were responsible for validating, reminding organizations that preventing these failures requires identifying where trust changes hands and ensuring that privileged components validate both the request and the boundary of the operation they perform.