CVE-2026-6437: Mount Option Injection in Amazon EFS CSI Driver

The Amazon Elastic File System (EFS) Container Storage Interface (CSI) driver facilitates the integration between Kubernetes clusters and Amazon EFS. It manages the lifecycle of EFS volumes, including provisioning, attaching, and mounting filesystems to containers. The driver operates as a daemonset across worker nodes, interacting directly with the underlying host operating system to execute storage mount operations.

A vulnerability exists within the driver's handling of specific volume attributes during the mounting phase. The driver is susceptible to CWE-88: Improper Neutralization of Argument Delimiters in a Command. This argument injection flaw manifests when the driver processes the volumeHandle and mounttargetip fields supplied within a Kubernetes PersistentVolume object.

The vulnerability arises because the driver relies on the host system's mount utility, which parses options separated by commas. The lack of input sanitization creates a distinct attack surface. Users with sufficient cluster privileges to define persistent volume attributes can supply maliciously crafted strings containing commas, which are subsequently passed directly to the system execution context.

These crafted strings are blindly concatenated into the final mount command constructed by the CSI driver. This permits the injection of arbitrary filesystem flags alongside the legitimate parameters. The injection enables an attacker to alter the fundamental security context of the mounted volume, subverting intended administrative constraints.

The root cause of CVE-2026-6437 lies in the driver's failure to perform adequate input validation on user-controlled fields before passing them to the operating system's mount helper. In Linux environments, the mount command accepts a comma-separated list of options via the -o flag. The system interprets each comma as an explicit delimiter between distinct configuration directives.

When processing a mount request, the AWS EFS CSI Driver constructs an option string derived directly from the Kubernetes PersistentVolume attributes. For the mounttargetip field, the driver expects a valid IPv4 address. However, prior to version 3.0.1, the driver did not enforce this format requirement. An attacker can provide a value such as 10.0.0.1,noexec,nodev.

Similarly, the volumeHandle field typically contains an Access Point ID. The driver permits appending comma-separated values to this ID under normal circumstances. By injecting additional, unauthorized commas into this field, the attacker forces the underlying mount helper to parse the trailing strings as legitimate system-level mount flags.

The vulnerability is triggered at the precise moment the CSI driver invokes the mount system call. Because the driver runs with elevated privileges on the node, the injected options are applied globally to the target filesystem mount. The system inherently trusts the options formulated by the driver daemonset.

The vulnerability resides primarily within the pkg/driver/node.go file, specifically inside the NodePublishVolume function. This function is responsible for preparing the volume and executing the local node mount operation. The flaw centers around how elements from the volume context map are extracted and appended to the mount options array.

In versions prior to 3.0.1, the implementation blindly appended the MountTargetIp value without structural verification. The vulnerable code path extracted the context directly into the ipAddr variable and concatenated it to the mountOptions slice:

case MountTargetIp:
    ipAddr := volContext[MountTargetIp]
    mountOptions = append(mountOptions, MountTargetIp+"="+ipAddr)

The patch introduced in commit 51806c22c5754bfbdeca6910f15571a07921b784 addresses this flaw by implementing strict structural validation. The developers introduced a network parsing check to guarantee the input is exclusively a valid IP address. If the parsing fails, the function returns an immediate error, terminating the mount sequence.

case MountTargetIp:
    if net.ParseIP(v) == nil {
        return nil, status.Error(codes.InvalidArgument, fmt.Sprintf("Volume context property %q=%q is not a valid IP address", k, v))
    }
    mountOptions = append(mountOptions, MountTargetIp+"="+v)

This remediation effectively neutralizes the injection vector for the mounttargetip field. By utilizing net.ParseIP, the function implicitly rejects strings containing commas or other special characters. This structural typing eliminates the CWE-88 condition, ensuring only legitimate IP addresses reach the mount helper.

Exploitation of CVE-2026-6437 requires an attacker to possess specific authentication and authorization criteria within the target Kubernetes cluster. The attacker must hold Role-Based Access Control (RBAC) permissions capable of creating or modifying PersistentVolume objects. This constraint limits the attack surface primarily to authenticated tenants or compromised administrative accounts.

The attack begins with the creation of a malicious PersistentVolume definition. The attacker crafts the specification to include the target EFS volume handle while injecting commas into the susceptible fields. A typical payload targets the volumeAttributes section, defining a mounttargetip that appends desired system mount flags.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: malicious-efs-pv
spec:
  capacity:
    storage: 5Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  csi:
    driver: efs.csi.aws.com
    volumeHandle: fs-12345678
    volumeAttributes:
      mounttargetip: "10.0.0.1,rw,suid,exec"

Upon creating the object, the Kubernetes scheduler assigns the volume to a node. The EFS CSI driver daemonset on that node processes the request, invoking the mount helper with the injected string. The host OS executes the mount command, explicitly applying the attacker-defined rw, suid, and exec permissions to the underlying filesystem.

The vulnerability carries a Medium severity rating (CVSS v3.1: 6.5), reflecting the balance between its high potential impact and the significant privileges required for exploitation. The specific CVSS vector CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N indicates that the attack is network-exploitable and exhibits low complexity, but is fundamentally restricted by the need for high privileges (PR:H).

Successful exploitation results in high impacts to both confidentiality and integrity within the context of the mounted volume. By injecting arbitrary mount options, an attacker can bypass explicit administrative constraints. For instance, an administrator may configure an EFS volume to be inherently read-only (ro) and restrict executable execution (noexec) for security purposes.

An attacker can override these restrictions by appending rw and exec via the injection vector. This allows the attacker to write arbitrary data to restricted administrative shares or execute malicious binaries directly from the network filesystem. Additionally, injecting the suid flag could permit the execution of setuid binaries, facilitating further privilege escalation within the pod container context.

Despite the requirement for PersistentVolume creation rights, this vulnerability presents a material risk in multi-tenant Kubernetes environments. Managed service providers or organizations utilizing strict separation of duties may face scenarios where tenant boundaries are compromised. The exploit maturity currently remains at the proof-of-concept level, with no documented weaponization in the wild.

The primary and most effective remediation strategy is upgrading the Amazon EFS CSI Driver to version 3.0.1 or later. This release contains the deterministic structural validation patches that eliminate the comma injection vector. Cluster administrators should deploy the updated driver via standard Helm or manifest upgrade procedures.

In environments where immediate patching is administratively blocked, organizations must enforce strict Role-Based Access Control (RBAC) limitations. The ability to create or modify PersistentVolume and StorageClass objects must be restricted exclusively to trusted cluster administrators. Standard users and automated CI/CD pipelines should only interact with PersistentVolumeClaim objects, which do not expose the vulnerable volumeAttributes fields.

Further defense-in-depth can be achieved through the implementation of Kubernetes admission controllers. Administrators can deploy an Open Policy Agent (OPA) Gatekeeper or Kyverno policy designed to inspect incoming PersistentVolume requests. The policy should utilize regex validation to reject any volumeHandle or mounttargetip fields containing comma characters, neutralizing the exploit payload before it reaches the datastore.

Security operations teams should monitor Kubernetes audit logs for anomalous PersistentVolume creation events. High-fidelity detection logic should trigger alerts on any volumeAttributes parameters containing commas, specifically focusing on fields designed strictly for IP addresses or alphanumeric identifiers.