Windows ECS Agent FSx mount flow allows SYSTEM command injection
TL;DR - On Windows ECS worker instances that mount FSx for Windows File Server volumes, a crafted username in an ECS task definition reaches the FSx volume mounting code unsanitised and executes with SYSTEM privileges on the underlying host. Update amazon-ecs-agent to 1.103.0. ECS on Fargate is not affected.
What happened
amazon-ecs-agent runs on container instances and handles task scheduling, platform integrations, and volume mounts. AWS disclosed CVE-2026-7461 (CWE-78): the agent's FSx for Windows File Server volume mounting flow passes credentials from the task definition to a shell command without sanitising them. An attacker who controls the FSx credentials value in a task definition - specifically the username - can inject arbitrary commands that execute as SYSTEM on the host.
Affected versions span 1.47.0 through 1.102.2. The fix ships in 1.103.0.
Task definitions sit at the intersection of CI/CD pipelines, internal deployment tooling, and developer IAM permissions. That makes this worth taking seriously: a single compromised build role or overly permissive ecs:RegisterTaskDefinition grant can turn into host-level compromise across an entire Windows container fleet.
Who is impacted
- Teams running Amazon ECS on Windows EC2 instances that mount FSx for Windows File Server volumes via task definitions.
| Item | Detail |
|---|---|
| Affected component | amazon-ecs-agent on Windows (FSx for Windows File Server volume mounting) |
| Impacted versions | 1.47.0 through 1.102.2 |
| Fixed version | 1.103.0 |
| Not affected | ECS on Fargate |
What to do now
- Update to
amazon-ecs-agent1.103.0by migrating to the latest Amazon ECS-optimised Windows AMI."This issue has been addressed in ECS agent version 1.103.0. We recommend upgrading to the latest Amazon ECS-optimized Windows AMI with an updated ECS agent version."
- If you cannot update immediately, apply the AWS-listed mitigations:
"Customers who cannot update to the latest AMI can restrict ecs:RegisterTaskDefinition permissions to trusted IAM principals only and restrict write access to Secrets Manager secrets referenced in FSx volume configurations."
- Inventory every place task definitions are authored and registered - CI/CD pipelines, internal tooling, developer roles. Tighten
ecs:RegisterTaskDefinitionto the smallest set of principals you can justify. - On Windows clusters that mount FSx volumes, watch for unexpected task-definition changes and anomalous task launches during your rollout window.
Related
Content is AI-assisted and reviewed by our team, but issues may be missed and best practices evolve rapidly, send corrections to [email protected]. Always consult official documentation and validate key implementation decisions before making design or security choices.