BreakingFormation: Orca Security Research Team Discovers AWS CloudFormation Vulnerability


Jan 13, 2022

Reading time:

4 Minutes

Orca Security’s vulnerability researcher, Tzah Pahima, discovered a vulnerability in AWS allowing file and credential disclosure of an AWS internal service. This zero-day, which AWS completely mitigated within 6 days of our submission, was an XXE (XML External Entity) vulnerability found in the CloudFormation service. This could have been used to leak sensitive files found on the vulnerable service machine and make server-side requests (SSRF) susceptible to the unauthorized disclosure of credentials of internal AWS infrastructure services.

At Orca Security, our customers are our priority in everything we do, including vulnerability research. Our primary goal is always to protect you and your cloud estate. Prior to this post, and before announcing the CloudFormation vulnerability publicly, our researchers worked with AWS to ensure that the issue was fixed to avoid putting our customers — and AWS’ customers — at risk.

What was the Zero-Day AWS BreakingFormation Vulnerability?

If you use AWS, then you might be familiar with CloudFormation, the service that enables you to easily provision AWS resources (such as EC2 instances and S3 buckets) using templates. CloudFormation also allows you to use API calls to dynamically create and configure resources. The Orca Security Research Team discovered a zero-day vulnerability that allowed us to compromise a server within CloudFormation, which in turn, led to us running as an AWS infrastructure service.

Leveraging an anomaly in the way that CloudFormation renders templates allowed us to trigger an XXE vulnerability, which we used to read files and perform HTTP requests on behalf of the server. The server contained multiple service binaries containing AWS server-side logic, as well as configuration files for connecting to internal AWS endpoints and services.

Our research team believes, given the data found on the host (including credentials and data involving internal endpoints), that an attacker could abuse this vulnerability to bypass tenant boundaries, giving them privileged access to any resource in AWS.

This is what a file disclosure looks like (AWS employees’ information on the right side of the screen was redacted):

We didn’t want to interfere with the service’s operation. To ensure to whom these credentials belonged, but in a non-invasive way, we used the leaked credentials to presign an S3 URL and then used the SSRF to try and access our own S3 bucket to see which identity was involved. The resulting logs tell us who these credentials belong to. The result was an Access Denied CloudTrail log entry, with the identity shown below:

Note: The “userIdentity” field shows that an AWS service, not CloudFormation’s public principal but rather an internal service used by AWS, tried to access our storage bucket.

Reforming the Ranks

We immediately reported the issue to AWS, who acted quickly to fix it. The AWS security team coded a fix in less than 25 hours, and it reached all AWS regions within 6 days.

Orca Security researchers helped test the fix to ensure that this vulnerability was correctly resolved, and we were able to verify that it could no longer be exploited.


  • 09/09/2021 – Vulnerability reported to the AWS security team.
  • 09/10/2021 – AWS sent us a message, saying they had made a code change and had started deploying it.
  • 09/15/2021 – The code change reached every AWS region.

The Orca Security Research Team is dedicated to ethically advancing cloud security in close partnership with the cloud service platforms that we help protect. 

If you’d like to learn more about Orca Security I invite you to experience our tech and talent first-hand with a no-obligation, free cloud risk assessment. You’ll get complete visibility into your public cloud, a detailed risk report with an executive summary, and time with our cloud security experts.


Tzah Pahima is a Cloud Security Researcher at Orca Security. Follow him on Twitter @tzahpahima