ECScape: New AWS ECS flaw lets containers hijack IAM roles without breaking out - Source: www.csoonline.com

Naor Haziz’s discovery shows how a compromised container on EC2-backed ECS tasks can impersonate the ECS agent and steal IAM credentials from other tasks—without host access.

At Black Hat USA 2025, Sweet Security’s Naor Haziz revealed a significant privilege escalation flaw in Amazon ECS that allows a low-privilege container running on an EC2-backed task to hijack higher-privileged IAM roles from other containers on the same host.

Dubbed ECScape, the flaw stems from ECS’ internal credential distribution. The ECS control plane delivers task IAM credentials via an undocumented internal WebSocket protocol, Agent Communication Service (ACS), which a container attacker can tap into if they first obtain the EC2 instance role credentials from Instance Metadata Service (IMDS).

“In practice, this means a compromised app in your ECS cluster could assume the role of a more privileged task by stealing its credentials – as long as they are running on the same instance,” Haziz said in a blog post, adding that the flaw also exposes task execution roles which, when compromised, can be abused to extract secrets or artifacts.

Haziz originally set out to build an eBPF-based real-time monitoring tool for ECS workloads. While doing so, he intercepted communication between the ECS agent and AWS backend as part of his debugging process, which is when he noticed the undocumented WebSocket channel.

From lowly tasks to privileged IAM roles

Thanks to the default availability of IMDS, any container (with low-level access) on an EC2-based ECS instance can read the instance role credentials intended for the ECS agent.

“No container breakout (no hostroot access) was required – however IMDS access was required via clever network and system trickery from within the container’s own namespace,” Haziz noted, adding that accessing IMDS lets any container impersonate an ECS agent. AWS has documentation on how to prevent or limit access to IMDS.

Armed with those instance role credentials, the attacker can forge communication over the ACS WebSocket. This allows them to intercept or request IAM credentials of other running tasks, even if those tasks are supposed to be isolated by IAM roles. Essentially, the compromised container escalates by masquerading as the orchestrator ECS agent responsible for managing and orchestrating tasks.

“The stolen keys (IAM credentials) work exactly like the real task’s keys,” Haziz said. “AWS CloudTrail will attribute API calls to the victim task’s role, so initial detection is tough – it appears as if the victim task is performing the actions.” This lets attackers be invisible in the logs because AWS thinks the victim is doing everything.

Fargate is comparatively safe

Amazon’s design makes the EC2 host, not the container, the security boundary. When multiple tasks with varying IAM roles share the same EC2, the risk of lateral escalation via ECScape increases. AWS did not immediately respond to CSO’s request for comment.

Sweet Security has recommended mitigations that include disabling or restricting IMDS access from less-trusted tasks so they can’t obtain instance credentials, avoiding co-hosting low and high-privilege tasks on the same EC2 instance, and switching to AWS Fargate, which provides better task isolation.

“AWS Fargate tasks don’t share an underlying host with other tasks – each Fargate task runs in its own micro VM with its own isolated IMDS and ECS agent,” Haziz explained. “ECScape does not apply to Fargate because there is no co-tenancy of the instance.”

A CVE ID has been requested for ECScape, and Sweet Security has published a proof-of-concept (PoC) code for the vulnerability on GitHub. Haziz also shared a live demo of ECScape, adding that unmitigated instances require no misconfigurations on the user’s part. “All the default behaviors and settings of ECS on EC2 are enough for the attack to work,” he added.

SUBSCRIBE TO OUR NEWSLETTER