Massive Security Flaw in Amazon ECS Exposes AWS Credentials to Attackers

Amazon’s Elastic Container Service (ECS), widely used for managing containerized applications on EC2 instances, harbors a serious vulnerability that could allow attackers to hijack credentials from other containers sharing the same host. This weakness, uncovered by security researcher Naor Haziz and dubbed “ECScape,” exposes how malicious containers can steal AWS Identity and Access Management (IAM) credentials, enabling them to escalate privileges and access sensitive resources across supposedly isolated workloads.

How ECScape Exposes AWS Containers to Credential Theft

The vulnerability hinges on ECS’s internal process of delivering IAM credentials to running containers. In ECS on EC2, the control plane assigns IAM roles to each task and relays those credentials to the ECS agent via a WebSocket connection. The agent then distributes these credentials to containers through a local metadata endpoint (169.254.170.2). Haziz’s attack takes advantage of this flow by allowing a malicious container to impersonate the ECS agent itself.

By stealing the EC2 instance’s own IAM credentials from the instance metadata service (IMDS), the attacker can forge a WebSocket connection to the ECS control plane, requesting credentials for all other tasks running on the same EC2 instance. This trick allows the attacker to harvest permissions from higher-privilege containers that were never meant to be shared. In a live demo at Black Hat USA 2025, Haziz showed how even low-privilege containers could exploit this flaw to access critical resources like S3 buckets and database secrets belonging to other tasks.

The Real-World Threat and AWS’s Response

What makes ECScape especially dangerous is its stealth. Because AWS CloudTrail logs attribute API calls to the roles of the compromised tasks, the malicious activity looks like legitimate operations performed by authorized workloads. This obfuscation complicates detection and incident response, giving attackers a covert way to pivot through cloud resources undetected.

When Haziz reported ECScape to AWS, the company classified this as “working as designed” rather than a security vulnerability, emphasizing that containers on the same EC2 host belong to the same trust boundary. AWS updated their documentation to warn users of this risk and now strongly advises the use of AWS Fargate, which isolates containers more securely, to mitigate potential cross-task credential leaks.

Security experts suggest multiple countermeasures, including restricting or disabling IMDS access for containers, isolating sensitive workloads on separate EC2 instances, enforcing strict least-privilege IAM roles, and employing real-time monitoring to spot unusual credential usage. However, the ECScape case highlights an ongoing cloud security challenge: container isolation on shared infrastructure remains fragile.

What Undercode Say:

The ECScape vulnerability highlights a critical blind spot in how AWS ECS handles credential distribution and task isolation on EC2 instances. While AWS’s stance that containers on the same host share trust boundaries may be technically sound, it clashes with common security best practices expecting workload isolation. This disconnect opens doors for attackers to exploit assumptions built into the container ecosystem.

Containers, by design, are supposed to provide process and network isolation, but this research reveals that the metadata services and credential proxies in ECS become a shared attack surface. The fact that a compromised container with minimal permissions can harvest credentials from more privileged neighbors undermines the fundamental principle of least privilege and weakens security assurances for cloud-native applications.

AWS’s recommendation to move towards Fargate reflects a trend to abstract away shared infrastructure to enhance isolation, but it comes with higher costs and operational trade-offs. Organizations relying on ECS on EC2 must proactively implement robust isolation techniques, such as running sensitive tasks on dedicated instances or disabling IMDS access where possible. Moreover, active monitoring and anomaly detection become critical defenses against stealthy credential abuse.

This case also reveals a broader concern: cloud providers often assume customers understand trust boundaries within their services, but in reality, these boundaries are nuanced and poorly documented until exploited. Enterprises need to reevaluate their container security strategies with an emphasis on minimizing shared resource exposure, leveraging zero-trust principles, and demanding clearer provider guarantees on workload isolation.

Ultimately, ECScape is a wake-up call that cloud-native security requires constant vigilance and adaptation. Attackers will continue probing trust assumptions baked into container orchestration systems, and defenders must respond by implementing layered security controls, transparency, and tighter segmentation across all cloud workloads.

🔍 Fact Checker Results:

✅ ECScape vulnerability confirmed by independent security researcher Naor Haziz.
✅ AWS states that this behavior is by design but warns customers in documentation.
✅ Mitigation advice includes moving to AWS Fargate and restricting metadata access.

📊 Prediction:

The discovery of ECScape will push organizations to rethink container security on shared EC2 instances, accelerating adoption of serverless container solutions like AWS Fargate or Kubernetes clusters with enhanced workload isolation. Cloud providers may face increased pressure to offer more robust built-in container isolation or credential management mechanisms to prevent cross-task leaks. Expect growth in third-party monitoring and detection tools focusing on unusual IAM role activities and metadata access patterns as enterprises seek to shore up defenses against this subtle but powerful attack vector.