Critical Privilege Escalation Vulnerability in Amazon ECS Exposes IAM Credentials to Hijacking

Amazon’s Elastic Container Service (ECS), widely used to deploy containerized applications on the cloud, has been revealed to harbor a severe security flaw that allows attackers to escalate privileges and hijack IAM credentials across containers on the same EC2 instance. This discovery raises major concerns about container isolation and the safety of cloud environments relying on ECS.

Introduction: A Hidden Risk in the Heart of Amazon ECS

Amazon ECS is designed to securely run multiple containers on a shared EC2 host, with strict role and permission boundaries to isolate workloads. However, recent research unveiled a critical vulnerability that shatters this assumption. A researcher demonstrated how attackers can exploit an undocumented internal protocol within ECS to move laterally from one compromised container to others, gaining unauthorized access to their IAM credentials and cloud resources. This flaw exposes a blind spot in Amazon’s container security model, putting countless cloud deployments at risk.

the Original Report

At Black Hat USA 2025, Naor Haziz, a senior developer at Sweet Security, presented a striking new attack technique dubbed “ECScape.” By reverse-engineering ECS internals, Haziz uncovered that the ECS control plane communicates task credentials to the ECS agent over a WebSocket channel managed by the Agent Communication Service (ACS). This channel, previously undocumented, proved vulnerable.

Haziz demonstrated that by forging and signing ACS WebSocket requests, an attacker could impersonate an ECS agent and intercept IAM credentials for any ECS task running on the same EC2 instance. This means an attacker with access to a low-privilege container can escalate their privileges by stealing credentials from high-privilege containers co-located on the same host.

Unlike typical assumptions that containers are isolated, ECScape bypasses such boundaries without requiring misconfiguration. The root cause lies in Amazon’s default setup where the Instance Metadata Service (IMDS) is enabled, providing a gateway for attackers to query credentials. Haziz also found that APIs exposed by ECS allow attackers to enumerate and target other containers’ credentials on the instance.

Despite publishing a proof-of-concept on GitHub and alerting AWS, the cloud giant controversially downplayed the severity, refusing to issue a CVE or release patches. Instead, AWS advised customers to implement their own mitigations: disabling or restricting IMDS, limiting ECS agent permissions, avoiding running privileged and untrusted containers on the same host, and migrating to AWS Fargate for stronger isolation.

Haziz stressed that the complexity of ECS roles and metadata APIs unintentionally paved the way for this exploit, and fixing it would be a significant engineering challenge requiring widespread ECS agent updates.

What Undercode Say:

This revelation about the ECScape vulnerability is a wake-up call for the cloud and container security community. Amazon ECS is a cornerstone service powering numerous enterprise applications, and the implicit trust in container isolation has been severely undermined. The fact that an attacker can leapfrog from a compromised container to others within the same EC2 host threatens the foundational principle of multi-tenancy security.

The root of this problem is multifaceted. AWS’s default enablement of IMDS, combined with undocumented WebSocket communication channels that expose credentials internally, creates a large attack surface. It reveals a disconnect between AWS’s drive for developer convenience and the complexities of secure access management. While IAM roles and task-based permissions were meant to simplify security, they have introduced subtle flaws that adversaries can exploit.

Moreover, AWS’s reluctance to classify this as a critical vulnerability or provide official patches shifts the burden to customers. This approach could lead to inconsistent security postures across the ecosystem, as many organizations may not be equipped to fully implement recommended mitigations. Customers must rigorously audit their ECS deployments and consider architectural changes such as moving sensitive workloads off shared EC2 hosts or adopting serverless container services like Fargate.

This case also highlights the challenges of cloud security transparency and the delicate balance providers must maintain between exposing powerful APIs and safeguarding internal communication protocols. It underscores the need for continuous independent security research and better collaboration between cloud providers and the security community.

Finally, the technical difficulty in patching ECScape suggests this issue will linger unless AWS takes decisive action. Legacy ECS instances running outdated agents remain vulnerable, making it critical for organizations to proactively harden their environments.

Fact Checker Results:

✅ Naor Haziz presented ECScape at Black Hat USA 2025, confirming the vulnerability’s credibility.
✅ AWS acknowledged the findings but disagreed on the severity, consistent with their official response.
✅ No CVE or official patch has been issued as of the report’s publication.

📊 Prediction: The Future of ECS Security Post-ECScape

This ECScape vulnerability will likely spark a new wave of scrutiny on container isolation mechanisms in cloud environments. Expect organizations running ECS on EC2 to accelerate migrations toward managed container services like AWS Fargate or alternative platforms offering stronger built-in isolation.

AWS may face mounting pressure from the security community and large customers to release official patches or redesign ECS agent communication to close this loophole. Enhanced controls around IMDS and metadata exposure will become a key focus in container security best practices.

In the longer term, this incident could influence cloud providers to adopt more transparent vulnerability disclosure policies and improve collaboration with external researchers. Meanwhile, attackers may begin exploiting this technique in real-world scenarios, making timely mitigations critical.

Ultimately, ECScape marks a turning point, highlighting the urgent need to rethink security assumptions in multi-tenant container orchestration systems. The battle for secure cloud containers is far from over, but awareness and proactive defenses will shape the next chapter.