EFS CSI Driver fixes mount option injection in Kubernetes

TL;DR — A mount option injection in the Amazon EFS CSI Driver lets Kubernetes principals who can create PersistentVolumes inject unauthorized mount flags via unsanitized volumeHandle/mounttargetip fields.

What happened

The Amazon EFS CSI Driver is a Kubernetes Container Storage Interface (CSI) driver that mounts Amazon Elastic File System (EFS) volumes into pods.

AWS reported CVE-2026-6437: under certain circumstances, unsanitized values from two user-controlled inputs are passed to the mount command, enabling injection of arbitrary mount options:

• Access Point ID inside the volumeHandle
• mounttargetip volumeAttribute

In both cases, an attacker can append comma-separated values, and the mount utility parses them as separate mount options.

Why it matters: storage drivers run with elevated permissions and sit on a high-trust boundary between Kubernetes control plane intent and node-level filesystem mounts. In multi-tenant clusters, “who can create PVs/StorageClasses” is often broader than intended, making this class of injection a practical platform risk.

Who is impacted

• Kubernetes clusters using the Amazon EFS CSI Driver at versions <= v3.0.0.
• Environments where non-admin users (or compromised workloads/identities) have privileges to create PersistentVolumes (and potentially StorageClass resources).

What to do now

• Follow vendor remediation guidance and apply the fixed release.

  "This issue has been addressed in EFS CSI Driver version v3.0.1"

• Audit RBAC for who can create or modify PersistentVolume and StorageClass resources; AWS explicitly recommends tightening these permissions.

  "Restrict PersistentVolume and StorageClass creation to cluster administrators using Kubernetes RBAC"

• Inventory clusters (including forks/derivative builds) to ensure the remediation is carried into internal images/charts and GitOps-managed deployments.