If we had to pick the single bug class that's produced the most "critical" severity findings in our reports across the engagements we have run, it's server-side request forgery — and specifically, SSRF against cloud metadata endpoints. The Capital One breach in 2019 made the pattern famous. The reality is that the pattern was, and still is, deeply common.
What metadata endpoints do
Every major cloud provider — AWS, GCP, Azure, Oracle — exposes a metadata service on a fixed internal IP address (169.254.169.254 for AWS and GCP) that workloads can query to discover their identity, configuration, and short-lived credentials. The credentials returned have whatever IAM permissions the workload was assigned.
From inside the workload, this is convenient: you don't have to hardcode AWS keys; the workload bootstraps its own credentials at runtime. From an attacker's perspective, it's a single HTTP request from "I have SSRF" to "I have IAM credentials."
The SSRF
SSRF arises whenever an application takes a user-controlled URL or hostname and makes a server-side HTTP request to it. The common patterns:
- Webhooks: "we'll POST events to your URL."
- Image fetchers: "paste a URL and we'll generate a thumbnail."
- Profile picture URLs from social login providers.
- URL preview generators (Slack-style unfurling).
- OAuth callback exchanges where the redirect_uri is fetched server-side.
- PDF and email rendering pipelines.
If any of these accept an attacker-controlled URL and execute a server-side request, the next question is: can the attacker target the metadata endpoint?
The chain we find most often
- App accepts a URL for a profile image.
- App fetches that URL server-side to validate the image or resize it.
- Attacker submits
http://169.254.169.254/latest/meta-data/iam/security-credentials/. - App fetches it, gets back the role name.
- Attacker submits
http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name>. - App fetches it, gets back AWS credentials.
- App returns the response body in an error message, log entry, or generated image metadata.
- Attacker has functional AWS credentials.
The credentials are short-lived — often 6 hours — but that's enough to pivot. If the role had S3 read permissions, the attacker has read your S3. If it had Lambda invoke permissions, the attacker can invoke Lambdas. If it had IAM permissions (which it shouldn't, but often does), the attacker can grant themselves whatever they want.
IMDSv2: the fix that exists but isn't always deployed
AWS introduced IMDSv2 in 2019 specifically to mitigate this. IMDSv2 requires a session token, obtained via a PUT request, before metadata can be read. SSRF vulnerabilities that only support GET requests can't reach IMDSv2.
The fix has existed for five years. The number of AWS workloads still running with IMDSv1 enabled is not small. In our assessments, we routinely encounter EC2 instances and ECS tasks with IMDSv1 still available.
If you do nothing else after reading this, audit your fleet. aws ec2 describe-instances with the right filter tells you which instances allow v1. Setting HttpTokens=required on all of them is a one-line fix that closes most SSRF-to-credential chains.
The defenses, in priority order
- Disable IMDSv1 everywhere. This is the highest-leverage single action.
- Implement strict allowlists for any server-side URL fetcher. Reject private IP ranges, link-local, loopback, and any non-allowlisted hostnames.
- Validate after DNS resolution, not just before. Hostnames can resolve to private IPs; validation must happen on the resolved address.
- Limit IAM permissions on the role. Even if SSRF reaches metadata, the credentials are useful only to the extent the role is permissive. Most roles are too permissive.
- Use VPC-only services where possible. Network-layer controls remove the metadata endpoint from reachability.
The honest summary
SSRF is the bug class that has consistently bridged the gap between "we have a low-severity issue in our image processor" and "we have a critical breach." It's why we test it on every engagement, and why finding it is rarely the surprise — finding the cleanup is.