flawopen.com/Incidents/Capital One SSRF
A company has a receptionist who will fetch documents from any address you give them. Inside the building, there is an unmarked door that hands out the company's master keys to anyone who knocks — the designers assumed only staff could ever reach it. You ask the receptionist to knock on that door for you. They do, because it is just an address, and they bring you the keys.
In July 2019 Capital One disclosed a breach affecting roughly 100 million individuals in the United States and a further 6 million in Canada — credit card application data spanning years, including names, addresses, dates of birth, self-reported income, and a smaller volume of Social Security and bank account numbers.
The intrusion did not begin with stolen credentials or malware. It began with a misconfigured web application firewall running on an EC2 instance that could be induced to make outbound requests on an attacker's behalf. That is the whole primitive: make this server fetch a URL for me.
The attacker used the SSRF to make the instance request http://169.254.169.254/latest/meta-data/iam/security-credentials/ — an address only reachable from inside the instance. The metadata service answered, because from its perspective the request came from the instance itself.
That endpoint returned a temporary access key, secret key and session token for the IAM role attached to the instance. The attacker now held valid AWS credentials with whatever permissions that role carried.
The role was permitted to list and read S3 buckets. The attacker ran ListBuckets and then GetObject — ordinary, authorised-looking API calls — and exfiltrated the contents. Nothing further needed to be exploited; the credentials were legitimate.
Regulators subsequently found the underlying failures to be organisational as much as technical: inadequate identification and remediation of the misconfiguration, and insufficient detective controls to catch the anomalous access.
# Server fetches a user-supplied URL. # The classic SSRF sink. url = request.args["target"] resp = requests.get(url) return resp.text # target=http://169.254.169.254/latest/ # meta-data/iam/security-credentials/ # → returns live AWS credentials
# 1. Allowlist destinations. Resolve the # hostname, then check the resolved IP # is public — not loopback, private, # or link-local (169.254.0.0/16). # 2. Re-check after redirects. A 302 to # the metadata IP defeats naive checks. # 3. Enforce IMDSv2 so a plain GET # cannot retrieve credentials at all. # 4. Scope the IAM role down. It should # not have been able to read those # buckets in the first place.
Capital One is the reason SSRF stopped being treated as a second-tier bug class. Before it, SSRF was often triaged as an information-disclosure nuisance. After it, the industry understood that in a cloud environment SSRF is a credential-theft primitive — because the cloud platform itself puts a credential vending machine at a fixed, well-known, unauthenticated address inside every instance.
AWS introduced IMDSv2 in November 2019, requiring a PUT to obtain a session token and defaulting to a low IP hop limit. Both changes specifically break the "one blind GET" pattern this attack relied on. Equivalent hardening exists across other cloud providers.
169.254.169.254 is defeated by decimal encodings, DNS names that resolve to it, and redirects. Resolve, then check the address range.No — it removes one very high-value target. SSRF can still reach internal admin interfaces, databases, Kubernetes APIs, and other services that trust the network position of the caller. It remains a serious bug class on its own merits.
The vulnerable component in this case was a web application firewall, which is a useful reminder that security appliances are applications too. Filtering rules can raise the cost of exploitation but do not address the underlying design, which is that a server will fetch whatever address it is told to.