Database/Container, Kubernetes & orchestration

AWS EFS CSI Driver: crafted volumeHandle causes recursive deletion of directories on another filesystem

CVSS 5.1CVE-2026-85781Container, Kubernetes & orchestrationcurated

Impact

The volume deletion path does not verify that the access point named in a PersistentVolume's volumeHandle actually belongs to the target filesystem in that same handle. A Kubernetes user allowed to create PersistentVolumes can pair an access point from one filesystem with a different target filesystem and have the driver recursively delete directories on an EFS filesystem they were never authorised to touch. On a shared cluster where EFS carries datasets, checkpoints or shared home directories for multiple teams, this is cross-tenant data destruction driven entirely through the Kubernetes API. It is integrity and availability only; nothing is read back to the attacker.

Who can reach it

An authenticated Kubernetes user holding PersistentVolume creation privileges. PV creation is a cluster-scoped permission, so this is a privileged-user boundary rather than an ordinary pod tenant, but it is a permission that is often handed out to platform and ML teams.

What to do

Upgrade the driver to v3.4.1 and roll the CSI controller and node DaemonSet pods; no node drain or reboot is required. Until then, audit who holds create on persistentvolumes cluster-wide and remove it from anyone who does not need static provisioning.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-85781 https://aws.amazon.com/security/security-bulletins/2026-099-aws/https://github.com/kubernetes-sigs/aws-efs-csi-driver/releases/tag/v3.4.1

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.