SSRF to Cloud Metadata: The Attack Behind Capital One and How to Stop It

TL;DR — Server-Side Request Forgery (SSRF) is a bug class where your own server fetches a URL the attacker chose. In the cloud, that single primitive is catastrophic, because every VM runs next to a link-local metadata service at 169.254.169.254 that hands out live IAM role credentials to anything that asks. That exact chain — SSRF in a misconfigured WAF, metadata read, credential theft, S3 exfiltration — is how ~106 million people’s records left Capital One in 2019. The defenses are known and boring: IMDSv2, egress control, URL allowlists, and least-privilege roles. This is how each layer works.

SSRF never left the OWASP problem set, but it changed character in the cloud era. A classic SSRF against a self-hosted app could reach internal admin panels at best. The same bug against an EC2 instance, a Kubernetes pod, or a serverless function lands next to a service that dispenses the workload’s cloud identity. And the newest twist: every LLM agent and MCP tool that fetches URLs on a user’s behalf is a fresh, enthusiastic SSRF engine — we built a lab around exactly that in the MCP security lab post.

How the Attack Actually Chains

The Capital One breach of 2019 remains the cleanest public anatomy. A ModSecurity-based WAF running on EC2 was misconfigured in a way that let an attacker supply crafted requests that the WAF would relay onward — a textbook SSRF. The relayed request targeted the EC2 instance metadata service (IMDSv1), which answered with the credentials of the over-privileged IAM role attached to that instance. With those keys, the attacker enumerated and read the S3 buckets holding roughly 106 million people’s credit-card application records. No zero-day, no memory corruption — one forwarding bug plus a role that was far more powerful than its workload needed.

Generalize the chain and you get the playbook for every cloud SSRF:

Why Link-Local Metadata Exists — and Why It’s Loud

The metadata service is a genuinely good idea: it’s how an instance learns its own identity, user data, and temporary credentials without long-lived secrets on disk. It listens on 169.254.169.254, a link-local address present on every VM’s network interface, so it’s always “one hop” away. The three major clouds all run one:

• AWS EC2 IMDS at 169.254.169.254 (ECS task metadata has its own endpoint at 169.254.170.2).
• GCP Compute Engine metadata server, which rejects requests that don’t carry the Metadata-Flavor: Google header — a targeted anti-SSRF measure — and also drops requests bearing X-Forwarded-For.
• Azure IMDS, same link-local address, requiring a Metadata: true header.

The problem was never the concept — it’s that the first implementations (IMDSv1) answered any plain GET. The industry’s fix keeps the service but changes the protocol.

IMDSv2: Defense in Depth Against SSRF

AWS’s Instance Metadata Service v2, introduced after the Capital One breach, rebuilds the protocol around the assumption that attackers will get the server to make requests — but the wrong kinds of requests:

• PUT-first sessions. The caller must first issue a PUT to obtain a session token, then present that token on metadata GETs. Naive SSRF — “make the server GET my URL” — can’t bootstrap a session, because most SSRF primitives issue GETs and many can’t set arbitrary methods or repeat tokens across requests.
• Hop limit. The token response carries an IP TTL, defaulting to 1. A request relayed through a reverse proxy, NAT, or container bridge — the typical SSRF topology, exactly like the Capital One WAF — expires before the answer can return.
• Firewallable. Because v2 concentrates on the token endpoint, operators can allow legitimate metadata use while the old v1 surface is disabled outright (HttpTokens=required).

None of this makes SSRF harmless; a same-host SSRF on a container runtime can still satisfy v2’s handshake. The design’s honest goal is defense in depth — turning “any SSRF is game over” into “the SSRF must also defeat the protocol, the topology, and the network policy.”

The Controls That Actually Work

Treat metadata hardening as one layer of a stack, ordered by how many attacks each defeats:

1. Fix the fetch, not just the destination. Validate schemes (http/https only), resolve DNS yourself and pin the IP (defeats DNS-rebinding tricks), reject redirects, and check the resolved address against blocked ranges — link-local (169.254.0.0/16), loopback, private ranges — after resolution, before connecting.
2. Allowlists over blocklists. A webhook feature that should only reach four SaaS vendors should only connect to those four. An allowlist survives cloud providers adding new link-local services; a blocklist doesn’t.
3. Enforce modern metadata versions everywhere. IMDSv2 with HttpTokens=required as account default; on GCP and Azure the header requirements are already enforced by the platform — don’t let code paths or legacy images bypass them.
4. Segment egress. Workloads should not be able to initiate arbitrary traffic to link-local space or to each other freely. This is the same network-policy discipline described in the Kubernetes security fundamentals post — an SSRF inside a pod whose egress is scoped to its real dependencies ends at step 2 of the chain.
5. Least-privilege the role, every time. The metadata service can only leak what the role can do. A WAF instance role that can read an S3 bucket of consumer records is the actual vulnerability; the SSRF was just the trigger.
6. Detect it. Metadata access from unusual processes, IMDS token issuance anomalies, and cloud API calls from instance identities touching data they’ve never touched are all high-signal signals — the kind of rules that belong in the Sigma pipeline from the detection engineering post.

The New SSRF Frontier: Agents That Fetch

The 2019 attack needed a misconfigured WAF. The 2026 version needs only an AI feature: any assistant that previews links, imports documents by URL, or calls MCP tools that fetch resources will follow attacker-controlled URLs from inside your perimeter — with cloud credentials ambient in its environment. The mitigation list is identical (allowlists, egress scoping, no ambient secrets in the fetch path), but the audit surface is new: inventory everything in your stack that performs server-side fetches, including the ones product shipped last quarter. If you don’t know the list, that’s the finding.

Key Takeaways

• SSRF turns your server into the attacker’s HTTP client; in the cloud, the metadata service at 169.254.169.254 turns that primitive into credential theft.
• Capital One 2019: SSRF in a WAF → IMDSv1 → over-privileged IAM role → S3 exfiltration of ~106 million records — no exploit code required.
• IMDSv2 mitigates the primitive with PUT-token sessions and a default hop limit of 1; GCP and Azure enforce anti-SSRF headers platform-wide.
• Layered fixes beat any single one: URL allowlists, post-resolution IP checks, redirect refusal, egress segmentation, least-privilege roles, and detection on metadata/identity anomalies.
• AI agents and URL-fetching tools are the largest new SSRF surface — audit every server-side fetch feature you run.

FAQ

What is SSRF?
Server-Side Request Forgery: a vulnerability where an attacker controls the destination of a request your server makes, letting them reach internal-only services from inside your perimeter.

Why is 169.254.169.254 special?
It’s the link-local address of cloud metadata services. Every major cloud runs one there, and on AWS (IMDSv1) a plain GET returned the workload’s live IAM credentials.

What is IMDSv2 and does it fix SSRF?
A session-oriented redesign of EC2’s metadata service: a PUT-issued token plus an IP hop limit of 1. It defeats most relayed SSRF paths but is defense in depth, not a fix for the underlying bug.

How did Capital One’s breach actually work?
A misconfigured ModSecurity WAF relayed attacker requests (SSRF), those requests hit IMDSv1 and returned the instance role’s IAM keys, and those keys were used to read S3 buckets of ~106 million records.

Do GCP and Azure have the same problem?
They expose metadata at the same address, but require anti-SSRF headers (GCP: Metadata-Flavor; Azure: Metadata: true), which blocks the simplest request-forgery patterns.

What’s the single highest-value hardening step?
Shrinking workload IAM roles. Metadata can only leak a role’s power — an instance role scoped to exactly what the workload needs turns credential theft into a dead end.

References

1. AWS Security Blog — Defense in depth against SSRF (IMDSv2)
2. AWS Documentation — Configuring the instance metadata service (hop limit, HttpTokens)
3. Krebs on Security — What we can learn from the Capital One hack (2019)
4. ejj.io — Preventing the Capital One breach (SSRF breakdown)
5. Snyk — Technical analysis of the Capital One breach
6. Hacking the Cloud — EC2 metadata credentials via SSRF
7. Google Cloud — Metadata server overview (Metadata-Flavor header)
8. Microsoft — Azure Instance Metadata Service (Metadata: true)
9. OWASP Top 10 — A10:2021 Server-Side Request Forgery
10. PortSwigger Web Security Academy — SSRF

Current as of September 2026. Educational reference — apply controls per your cloud provider’s current hardening guidance, and test in a lab you own before production.

Published by Hmmnm

Hands-on cybersecurity tutorials, CVE breakdowns, and guided learning paths — written and lab-tested by the Hmmnm team.

Learning Paths · About Hmmnm · Editorial policy