The Role That Should Never Have Existed

Seven years on, Capital One is still one of the clearest public lesson in cloud security, and it is usually taught wrong. It may get filed under “SSRF vulnerability,” but under the hood, it reveals a broader lesson about cloud misconfigurations.

On 29 July 2019, Capital One disclosed that an attacker had taken data relating to roughly 106 million people across the United States and Canada. The attacker was Paige Thompson, a former Amazon Web Services engineer, who was arrested the same day and convicted on computer fraud charges in June 2022. The company's settlements reached around $190 million.

Here is the chain, and where it could have ended.

Four steps, each one permitted

A ModSecurity Web Application Firewall was running on an EC2 instance. It was misconfigured in a way that let it be used to relay requests.

The attacker used that to query the EC2 Instance Metadata Service. The metadata service returned temporary credentials for the IAM role attached to the instance. That is what the metadata service is designed to do for the workload running on the host, not for external actors.

Those credentials belonged to a role with permission to list and read from S3. So the attacker listed and read from S3 - more than 700 buckets, and roughly 30 GB of data.

At no point did anything malfunction. A misconfigured proxy did what a misconfigured proxy does. The metadata service returned credentials through a permitted path. The role used permissions it had been granted. Every step was, in the strict technical sense, authorized.

AWS later introduced IMDSv2 to make it significantly harder for attackers to use SSRF vulnerabilities to access instance metadata and credentials. Today, Aryon can enforce a policy requiring IMDSv2 at deployment, preventing EC2 instances configured to allow IMDSv1 from being created.

Why detection had so little to work with

This is the part that should worry anyone relying on monitoring alone. The API calls to S3 came from a legitimate IAM role, using valid temporary credentials, from an instance inside the environment. There was no malware, no exotic technique, no unusual protocol. To any monitoring system, it resembled a service doing its job.

One analysis of the incident put it plainly: standard security monitoring struggled because the activity looked like normal AWS API calls from an authorized service. An academic teardown published in ACM Transactions on Privacy and Security identified five distinct control failures: the misconfigured reverse proxy, the metadata service design that surrendered credentials, the over-provisioned IAM role, ineffective encryption, and inadequate intrusion detection.

Note the ratio. Four of those five are configuration decisions made before the attack. One is detection, and it was the last line, and it did not hold. Strip away the specifics and one question remains: why could a WAF read customer application data?

Nobody decided that on purpose. It happens through an ordinary sequence. A team needs something working. Narrow permissions produce an error under deadline pressure. The permission set widens until the error stops. The ticket closes. The role persists, and two years later it is load-bearing and nobody remembers why it has what it has.

Every step of that is rational. The result is a standing risk that a posture tool will report every scan, and that nobody will remediate, because narrowing permissions on a working production role is genuinely frightening.

What actually changed afterwards

AWS introduced IMDSv2, which requires a session token and closes off the naive SSRF path to the metadata service. That is a real improvement and it is worth enforcing. But notice what that fix does. It closes one route in. It does not remove the possibility of another route being created through a different cloud misconfiguration.

The lesson is not that every control must solve the entire attack. It is that every preventable configuration you stop before deployment removes one more link an attacker could use to build the attack chain.

The 2026 version of this incident

If you think this is a historical curiosity, look at where the industry's attention has moved.

The Cloud Security Alliance's Top Threats to Cloud Computing 2026, published in August 2026, ranks Inadequate Identity and Access Management at number one, citing excessive permissions and non-human identities among the drivers. CSA notes that "the rapid growth of non-human identities, machine-to-machine interactions, and autonomous decision-making has now surpassed what traditional management and oversight processes were designed to handle."

Capital One's over-permisioned role was attached to a workload. In 2026 those workloads are more numerous, created faster, and increasingly include AI agents operating with a developer's credentials. The mechanism has not changed. The volume has.

How Aryon helps

Aryon enforces cloud security policy at the moment of deployment, at the cloud control plane, so the risky configuration never exists.

Applied to this chain, there are two clear intervention points. Aryon can enforce a policy requiring IMDSv2 at deployment, preventing the unsafe configuration that allowed the SSRF path to reach the workload credentials. Aryon can also use access policies to prevent overly broad permissions from being abused, adding another layer of protection even if credentials are compromised. Instead of relying on a single control, the attack path can be broken at multiple points before it leads to sensitive data or resources.

That matters more than it sounds, because it does not depend on anyone noticing. There is no alert to triage, no finding to prioritize, no window between provisioning and detection.

Three things make that practical rather than theoretical:

• Aryon allow you to deploy policies in a safe to production manner.
• Help with the impact analysis, making it clear how the policy is going to impact the organization
• You see the impact before you enforce. The assessment shows exactly what a policy would have prevented against your real environment, so you tune it before anything is live.