BTC
ETH
SOL
BNB
GOLD
XRP
DOGE
ADA
Back to home
Security

[MEDIUM] Security Advisory: Amazon EFS CSI Driver has mount option injection via unsanitized volumeHandle and mounttargetip fields (github.com/kubernetes-sigs/aws-efs-csi-driver)

Kubernetes admins running Amazon EFS via the CSI driver face a serious vulnerability: attackers with PersistentVolume creation rights can inject arbitrary mount options.

Kubernetes admins running Amazon EFS via the CSI driver face a serious vulnerability: attackers with PersistentVolume creation rights can inject arbitrary mount options. This flaw, tracked in versions up to v3.0.0, lets them append malicious flags to the volumeHandle or mounttargetip fields. AWS patched it in v3.0.1, released recently, but clusters on older versions remain exposed.

The issue stems from poor input sanitization. The EFS CSI Driver passes volumeHandle—typically an Access Point ID—and mounttargetip directly into the Linux mount command without scrubbing commas. An attacker crafts a volumeHandle like “fsap-0123456789abcdef0,ro,nosuid,noexec” but flips it to “defaults,suid,exec” or worse. The mount utility treats comma-separated values as distinct options, applying them verbatim to the EFS mount in a pod.

Exploitation Mechanics

Consider a PersistentVolume spec. Normally, volumeHandle holds something like “fsap-0a1b2c3d4e5f67890”. Append “,noatime” and it becomes “fsap-0a1b2c3d4e5f67890,noatime”. The driver invokes mount with -o options including this string, so the filesystem mounts read-only or with relaxed security if the attacker controls it.

Proof-of-concept: In a YAML PersistentVolume, set spec.csi.volumeHandle to “fs-12345678,noexec,nosuid”. The mount command effectively runs:

mount -t efs -o tls,iam,fs-12345678,noexec,nosuid 10.0.0.1:/ /var/lib/kubelet/pods/xyz/volumes/...

Attacker inverts protections. Common injections disable noexec (allows binaries), nosuid (permits setuid), or nodev (mounts devices). Extreme cases mount unrelated filesystems if combined with other flaws, though EFS limits this to NFSv4.1 semantics.

Affected versions span <= v3.0.0, covering deployments since late 2023. Kubernetes CSI spec mandates drivers handle PersistentVolumeClaims (PVCs), but EFS CSI lagged on validation. SentinelOne's Shaul Ben-Hai reported it via coordinated disclosure; AWS fixed by URI-encoding or stripping commas in v3.0.1 commit.

Why This Exposes Clusters

Impact hinges on RBAC. If namespace users create PVs—common in multi-tenant setups like dev/test clusters—an attacker escalates. Inject “exec” to run binaries from EFS shares, bypassing pod security standards. Add “rw” overrides read-only policies. In finance or crypto ops, where K8s hosts sensitive workloads, this cracks container isolation.

Scale matters: Over 60% of enterprises run K8s per CNCF surveys, with AWS EKS dominant (40% market share). EFS usage surges for stateful apps—databases, ML storage—hitting 20%+ of EKS clusters. Similar CSI bugs hit other drivers: Longhorn (CVE-2023-50428), OpenEBS. Pattern? CSI spec lacks strict sanitization mandates, leaving it to implementers.

Risks amplify in EKS. Pods mount EFS across AZs for HA, but tainted options persist across nodes. DoS via “loop” or resource-heavy options like “sync” cripples performance. Privilege escalation? Chain with CVE-2024-21626 (runC) for host escapes, though unconfirmed here.

Skeptical take: AWS’s fix is solid—simple regex strips options—but why no earlier audit? CSI drivers handle kernel-level mounts; one lapse undermines zero-trust. Fair point: v3.0.0 was minor release; most stay pinned or auto-update via Helm charts.

Mitigate Now

Upgrade to v3.0.1+ immediately. Helm users run:

helm upgrade aws-efs-csi-driver oci://public.ecr.aws/aws-efs-csi-driver/aws-efs-csi-driver --version v3.0.1

Workaround: Lock PV/StorageClass creation to admins via RBAC. Deny create on PersistentVolumes/StorageClasses for non-admins:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: restrict-pv
subjects:
- kind: Group
  name: system:serviceaccounts:default
roleRef:
  kind: ClusterRole
  name: edit  # Customize
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: no-pv-create
rules:
- apiGroups: ["storage.k8s.io"]
  resources: ["persistentvolumes", "storageclasses"]
  verbs: ["get", "list"]  # No create

Audit logs for mount failures. Scan PVCs for suspicious handles. Long-term, enforce Pod Security Admission (PSA) baselines and CSI driver sigs for validation.

This vuln underscores CSI risks in cloud-native storage. K8s promises portability, but vendor drivers like EFS introduce blast radius. Operators: Patch, restrict, monitor. In high-stakes environments, one bad mount option topples defenses.

April 18, 2026 · 2 min · 13 views · Source: GitHub Security

Related