Server-Side Request Forgery (SSRF) is one of the most misunderstood vulnerabilities in web application security. In a traditional on-premises deployment, SSRF is dangerous: it can be used to scan internal networks, access internal services, and bypass network controls. But in cloud environments, SSRF takes on an entirely different risk profile. A basic SSRF vulnerability in a cloud-hosted application can provide direct access to IAM credentials, enabling an attacker to pivot from a web-layer finding to full cloud account compromise. The 2019 Capital One breach demonstrated this attack chain at scale — over 100 million customer records exfiltrated through SSRF targeting the AWS instance metadata service.
TL;DR: SSRF vulnerabilities in cloud-hosted applications can reach the instance metadata service at 169.254.169.254, which returns IAM credentials without requiring authentication. Those credentials can be used to access S3, Secrets Manager, and other AWS services. IMDSv2 raises the bar but does not fully prevent exploitation. Enforce IMDSv2, apply least-privilege IAM roles, and test every URL-fetching feature in your application.
The SSRF-to-Metadata Attack Chain
The attack proceeds through a predictable sequence that Lorikeet Security's pentesters encounter regularly in cloud-hosted web application assessments:
Step 1: Identify the SSRF vulnerability
SSRF occurs when a web application fetches a URL on behalf of the user without adequately validating the destination. Common locations include: webhook configuration endpoints (the application fetches the webhook URL to verify it), URL preview or screenshot features, document or image import from URL, PDF generation from HTML (headless browsers may follow redirects), and server-side proxies. Any feature where the server makes an outbound HTTP request based on user input is a potential SSRF vector.
Step 2: Reach the metadata endpoint
Once SSRF is confirmed — typically by making the server fetch an external URL you control — the next step is redirecting the request to http://169.254.169.254/. This is the link-local address reserved for cloud instance metadata services. It is reachable by any process running on the instance, including your web application. The address is the same across AWS EC2, GCP Compute Engine, and Azure VMs (though the API structure differs).
Step 3: Extract IAM credentials
On AWS, the path http://169.254.169.254/latest/meta-data/iam/security-credentials/ returns the name of the IAM role attached to the instance. A second request to http://169.254.169.254/latest/meta-data/iam/security-credentials/{role-name} returns the temporary Access Key ID, Secret Access Key, and Session Token for that role — refreshed automatically every few hours. These are fully functional AWS API credentials. An attacker who extracts them can use the AWS CLI or SDKs from any machine.
Step 4: Use credentials to escalate or exfiltrate
The impact of the extracted credentials depends entirely on what permissions the EC2 instance role has. In the Capital One case, the role had broad S3 access — enough to list and download data from over 700 buckets. In other cases, pentesters have found roles with Secrets Manager access (extracting database credentials and API keys), IAM permissions (enabling privilege escalation to more powerful roles), or RDS access.
Real-World Impact: The Capital One Breach
The Capital One breach is the canonical example of SSRF-to-metadata exploitation at enterprise scale. In 2019, a former AWS employee exploited an SSRF vulnerability in a misconfigured WAF running on an EC2 instance in Capital One's AWS environment. The WAF was configured to proxy requests, and an SSRF vulnerability allowed the attacker to craft requests that caused the WAF to fetch the IMDS endpoint and return the attached IAM role's temporary credentials.
Those credentials had access to over 700 S3 buckets containing Capital One customer data. The attacker exfiltrated data on approximately 106 million credit card applicants before the intrusion was detected — not by Capital One's security team, but by a tip received after the attacker posted about it in a public forum. The total cost of the breach exceeded $270 million in settlements, regulatory fines, and remediation costs.
The Capital One breach key takeaway: The SSRF vulnerability was the entry point, but the IAM role attached to the EC2 instance had far more S3 access than the application needed. Both layers failed: the web vulnerability (SSRF) and the cloud permission model (over-privileged IAM role). Fixing either one would have prevented the breach.
IMDSv2: The Mitigation and Its Limits
AWS released IMDSv2 (Instance Metadata Service version 2) specifically to address the SSRF-to-credentials attack chain. IMDSv2 introduces a session-oriented protocol that requires a two-step process to retrieve credentials:
- Send a
PUTrequest tohttp://169.254.169.254/latest/api/tokenwith the headerX-aws-ec2-metadata-token-ttl-seconds: 21600to obtain a session token - Use the returned token in subsequent
GETrequests via the headerX-aws-ec2-metadata-token: {token}
Simple SSRF that can only make GET requests cannot complete step 1 and therefore cannot retrieve credentials from an IMDSv2-only instance. However, IMDSv2 is not a complete solution:
- Advanced SSRF can bypass IMDSv2. If the SSRF allows setting custom HTTP headers or allows making PUT requests, the two-step IMDSv2 protocol can be completed. SSRF via server-side headless browsers (Puppeteer/Playwright), webhook handlers that follow HTTP methods, or SSRF in server-side proxy configurations often allows this.
- IMDSv2 enforcement must be configured. Enabling IMDSv2 does not automatically disable IMDSv1. You must explicitly set
HttpTokens: requiredon the instance to block IMDSv1 requests. Many existing instances remain IMDSv1-compatible unless this is explicitly enforced. - GCP and Azure have different implementations. GCP's metadata service requires a custom header (
Metadata-Flavor: Google) which blocks simple SSRF but not SSRF that can add headers. Azure requires a similar approach. Neither is equivalent to enforced IMDSv2.
SSRF Severity by Environment
| Environment | SSRF Severity | Primary Risk | Key Mitigation |
|---|---|---|---|
| On-premises (no cloud) | Medium-High | Internal network scanning, internal service access | Network egress filtering, allowlist outbound destinations |
| AWS EC2 (IMDSv1) | Critical | IAM credential theft → full cloud account pivot | Enforce IMDSv2, least-privilege IAM roles |
| AWS EC2 (IMDSv2 enforced) | High | Internal AWS service access, advanced SSRF still reaches IMDS | IMDSv2 + egress filtering + minimal IAM permissions |
| AWS Lambda / ECS | Critical | Environment variable credential theft, execution role abuse | Minimal execution role, egress control, secrets via Secrets Manager not env vars |
| GCP Compute Engine | High | Service account token theft via metadata service | Metadata-Flavor header enforcement, minimal service account scope |
What Pentesters Test for SSRF in Cloud Environments
In a cloud-hosted web application penetration test, SSRF testing is a structured activity that covers more than the obvious URL input fields:
- URL-accepting features. Every feature that accepts a URL — webhooks, imports, previews, integrations — is tested for SSRF. This includes testing with internal IP ranges (10.x, 172.16.x, 192.168.x), localhost, and the link-local metadata address.
- File upload and processing. SVG files, PDF generators, and document processors that resolve external references (XML external entities, embedded URLs, linked stylesheets) are common SSRF vectors that appear in unexpected places.
- Redirect chains. Applications that follow HTTP redirects may be redirectable to internal addresses even if the initial request is validated. Open redirects on trusted domains are sometimes used to bypass SSRF allowlists.
- DNS rebinding. In some configurations, DNS rebinding attacks can bypass allowlist checks — the initial DNS resolution returns an allowed IP, but by the time the HTTP request is made, the DNS has been updated to point to the metadata IP.
- Cloud-specific metadata paths. If SSRF to the metadata endpoint is confirmed, pentesters enumerate what credentials are available and what permissions those credentials hold — demonstrating real-world impact rather than just the vulnerability's existence.
Is your cloud-hosted application vulnerable to SSRF?
Lorikeet Security's cloud security assessments test SSRF vectors, IAM configuration, and the complete SSRF-to-compromise chain in AWS, GCP, and Azure environments.
