In 2019, an attacker stole the personal data of more than 100 million Capital One credit-card applicants in the US and Canada. The breach is the textbook example of a cloud-specific attack chain: a misconfigured web application firewall was abused through Server-Side Request Forgery (SSRF) to reach the AWS EC2 instance metadata service, retrieve the temporary credentials of the server's IAM role, and use those credentials to list and download the contents of Capital One's S3 storage buckets. It is a prominent example of the attack class AWS hardened the metadata service against with IMDSv2, and it is the breach I point to whenever someone treats SSRF as a low-severity bug.
The whole chain hinges on one cloud-platform detail that did not exist in the on-premise world: a server can ask a special internal address for its own cloud credentials, and if an attacker can make the server ask on their behalf, they walk away with the keys.
The attack chain
This is the canonical cloud metadata SSRF sequence, and every step is worth understanding because the pattern recurs across cloud breaches.
- A misconfigured WAF. Capital One ran a web application firewall (a ModSecurity instance) on an AWS EC2 server. It was misconfigured in a way that allowed Server-Side Request Forgery: the attacker could make the WAF server send an HTTP request to a destination of the attacker's choosing.
- SSRF to the metadata service. The attacker pointed that request at
http://169.254.169.254/, the EC2 Instance Metadata Service (IMDS). This is a special link-local address that every EC2 instance can query to learn about itself, including, critically, the temporary security credentials for the IAM role attached to the instance. From the metadata service's perspective, the request came from the server, so it answered. - Stolen IAM credentials. The metadata response handed over the temporary credentials for the server's IAM role, which was named for the WAF. Those credentials had permission to list and read S3 buckets, far more access than a firewall needs.
- Exfiltration from S3. Using the stolen role credentials, the attacker listed the S3 buckets the role could see (hundreds of them) and synced the data out, around 30 GB of customer information.
No malware, no novel exploit primitive. SSRF plus an over-permissioned role plus a metadata service that answered without authentication.
The heart of it: IMDSv1 and why IMDSv2 exists
The single most important technical lesson here is about the metadata service, because it is what turned a web-app SSRF into large-scale theft of the data behind the server's cloud credentials.
At the time of the breach, EC2 used what is now called IMDSv1: any process that could make an HTTP GET request to 169.254.169.254 got an answer, with no authentication. That is exactly what makes it so dangerous in combination with SSRF: the attacker does not need credentials to query it; they just need to make the server ask, and a single unauthenticated GET returns the role's keys.
AWS introduced IMDSv2 later in 2019, directly in response to this class of attack, and it is specifically designed to break the SSRF-to-credentials chain:
- It is session-oriented: the client must first send a
PUTrequest to obtain a session token, then include that token on subsequent requests. Most SSRF primitives can only make simple GET requests, so they cannot complete the handshake. - It refuses to issue a session token for a
PUTrequest that carries anX-Forwarded-Forheader, which is the fingerprint of a request that was proxied (as in SSRF through a WAF or proxy). - It defaults the IP hop limit to 1, so the metadata response cannot travel beyond the instance itself (for example, back out through a misconfigured container or proxy).
Enforcing IMDSv2 is the specific control that defeats this exact attack. If you run on AWS, requiring IMDSv2 on your instances is one of the highest-value, lowest-effort cloud-security changes you can make.
The attacker and the aftermath
The breach was carried out by Paige Thompson, a former Amazon Web Services engineer, whose familiarity with AWS internals is part of what made the metadata-service step second nature. The intrusion occurred around late March 2019; Capital One was tipped off and disclosed it on 29 July 2019, the same day the FBI arrested Thompson. She was convicted of wire fraud and computer-intrusion charges in 2022.
| Figure | What it was |
|---|---|
| ~106 million | Applicants affected (~100M in the US, ~6M in Canada). |
| ~140,000 | US Social Security numbers exposed. |
| ~80,000 | Linked bank account numbers exposed. |
| $80 million | Civil penalty from the OCC (2020) for the risk-management failures. |
| ~$190 million | Class-action settlement with affected customers. |
The regulatory response is part of the lesson. The Office of the Comptroller of the Currency fined Capital One $80 million, focusing not on the attacker's cleverness but on Capital One's own failures: the misconfiguration, the over-permissioned role, and the gaps in its cloud risk management. As with TalkTalk, the regulator treated a preventable misconfiguration as the bank's responsibility, not an excuse.
The lessons I take from it
Enforce IMDSv2 everywhere on AWS. This is the specific, decisive fix. Requiring IMDSv2 breaks the SSRF-to-credentials chain that this entire breach depended on. There is rarely a good reason to leave IMDSv1 enabled in 2026.
SSRF is a high-severity bug in the cloud. On a traditional server, SSRF might let an attacker scan the internal network. In the cloud, it reaches the metadata service and the credentials behind it, which is why the same bug is far more dangerous than it used to be. Treat any user-controlled URL fetch as a serious finding, validate destinations against an allow-list, and block requests to link-local and metadata addresses at the HTTP-client layer. The SSRF deep dive covers the defences in full.
Least privilege on cloud roles is not optional. The WAF's IAM role could list and read hundreds of S3 buckets. A firewall has no business with that access. If the role had been scoped to only what it actually needed, the stolen credentials would have been nearly worthless. Right-size every role to its real job, and review the broad ones.
Misconfiguration is the modern breach, not the zero-day. Nothing here was a software vulnerability in the classic sense. It was a chain of configuration and design choices (the WAF rule, the role permissions, IMDSv1) that each seemed acceptable alone and were catastrophic together. Cloud security is largely the discipline of getting those configurations right and reviewing them continuously.
Where to go next
For the mechanics of the bug, the SSRF deep dive and the focused cloud metadata SSRF article cover how the attack works and how IMDSv2 and allow-listing defend against it. For where SSRF sits among the web attack classes, see the web application security vulnerabilities taxonomy. And for a breach where the entry bug was different but the "over-permissioned access turned a foothold into a catastrophe" lesson is the same, see the Heartland breach.
Sources
Authoritative references this article was fact-checked against.
