CVE-2026-85781: Amazon EFS CSI Driver Privilege Escalation

CVE-2026-85781 Overview

CVE-2026-85781 is an authorization flaw in the Amazon Elastic File System (EFS) Container Storage Interface (CSI) Driver before version v3.4.1. The volume deletion component fails to verify that a supplied access point actually belongs to the target EFS filesystem. An authenticated Kubernetes user with PersistentVolume creation privileges can craft a volumeHandle that pairs an access point from one filesystem with a different target filesystem. This mismatch triggers recursive deletion of directories on an EFS filesystem the user is not authorized to access. The weakness is categorized under [CWE-283: Unverified Ownership].

Critical Impact
A privileged Kubernetes user can trigger recursive directory deletion on unrelated EFS filesystems, causing data loss across tenants sharing the cluster.

Affected Products

Amazon EFS CSI Driver versions prior to v3.4.1
Kubernetes clusters using the aws-efs-csi-driver for dynamic or static EFS provisioning
Multi-tenant EKS or self-managed Kubernetes environments backed by shared EFS filesystems

Discovery Timeline

2026-09-04 - CVE-2026-85781 published to the National Vulnerability Database (NVD)
2026-09-08 - Last updated in NVD database

Technical Details for CVE-2026-85781

Vulnerability Analysis

The Amazon EFS CSI Driver provisions and deletes Kubernetes PersistentVolume resources backed by EFS filesystems and access points. Each PersistentVolume carries a volumeHandle string that encodes the target filesystem identifier and an optional EFS access point identifier. During volume deletion, the driver uses these values to remove the underlying directory tree associated with the access point.

Before version v3.4.1, the deletion path did not validate that the referenced access point was owned by the referenced filesystem. An attacker with permission to create PersistentVolume objects can construct a volumeHandle that references an access point belonging to filesystem A while naming filesystem B as the target. When the volume is subsequently deleted, the driver recursively removes the directory subtree associated with the mismatched access point on filesystem B.

The impact is data destruction on filesystems the attacker was never authorized to touch. In multi-tenant clusters that mount separate EFS filesystems for different workloads or namespaces, this crosses the isolation boundary the platform team relied on.

Root Cause

The driver trusts caller-supplied identifiers in the volumeHandle without cross-checking that the access point identifier resolves to the same filesystem identifier passed alongside it. This is a missing ownership check on a storage resource, the pattern described by [CWE-283].

Attack Vector

Exploitation requires an authenticated Kubernetes principal with rights to create PersistentVolume objects, which is typically a cluster-scoped privilege. The attacker crafts a PersistentVolume manifest whose spec.csi.volumeHandle combines an access point from a filesystem they can enumerate with a different target filesystem identifier. Deleting that PersistentVolume invokes the driver's DeleteVolume code path and recursively removes directories on the mismatched filesystem. No network-level exploit code is required; the attack is executed entirely through legitimate Kubernetes API operations against the storage layer.

No public proof-of-concept exploit code is available. Refer to the AWS Security Bulletin 2026-099 for vendor-provided technical detail.

Detection Methods for CVE-2026-85781

Indicators of Compromise

Unexpected PersistentVolume create and delete sequences from accounts that do not normally manage storage
EFS access logs showing RemoveDirectory or recursive delete operations against paths that do not match the requesting workload's namespace
DeleteVolume events in efs-csi-controller pod logs referencing access point and filesystem identifiers that do not belong to the same tenant

Detection Strategies

Audit Kubernetes API server logs for create and delete verbs against persistentvolumes resources, and correlate the volumeHandle value against expected filesystem-to-access-point mappings
Parse efs-csi-controller container logs for DeleteVolume RPC calls and alert when the filesystem identifier does not match the owning filesystem of the access point
Enable AWS CloudTrail data events for EFS and alert on ClientRootAccess or bulk deletion patterns tied to the CSI driver's IAM role

Monitoring Recommendations

Baseline the set of PersistentVolume creators in each cluster and alert on new principals invoking storage APIs
Track EFS filesystem size and inode counts as a leading indicator of unauthorized recursive deletion
Forward Kubernetes audit logs and CSI controller logs to a centralized data lake for correlation and long-term retention

How to Mitigate CVE-2026-85781

Immediate Actions Required

Upgrade the Amazon EFS CSI Driver to version v3.4.1 or later on every cluster that mounts EFS filesystems
Review current ClusterRole and ClusterRoleBinding objects that grant create on persistentvolumes and remove access from principals that do not require it
Enable EFS backups or AWS Backup on production filesystems so recursive deletions can be recovered

Patch Information

The fix is available in the GitHub Release v3.4.1 for EFS CSI Driver. Cluster operators managing the driver through Helm, the EKS add-on, or manifest-based installs should update to this release. Amazon's guidance is published in the AWS Security Bulletin 2026-099.

Workarounds

Restrict PersistentVolume creation to trusted cluster administrators using Kubernetes Role-Based Access Control (RBAC) until the driver is upgraded
Use a separate IAM role per EFS filesystem for the CSI driver where possible, so a compromised driver instance cannot delete data on unrelated filesystems
Apply an admission controller policy, such as Kyverno or OPA Gatekeeper, to reject PersistentVolume objects whose volumeHandle combines a filesystem identifier with an access point that does not belong to it

bash

# Configuration example: verify installed driver version on an EKS cluster
kubectl -n kube-system get daemonset efs-csi-node \
  -o jsonpath='{.spec.template.spec.containers[0].image}'

# Upgrade via the EKS add-on API
aws eks update-addon \
  --cluster-name <cluster> \
  --addon-name aws-efs-csi-driver \
  --addon-version v3.4.1-eksbuild.1