Modern Cloud SSRF Hunting: Bypassing IMDSv2 Defenses
Imagine you're five hours into a bug bounty assessment. You find a classic webhook feature that lets you input an arbitrary URL. You spin up a Burp Collaborator payload, fire the request, and instantly get a DNS pingback. You have confirmed Server-Side Request Forgery (SSRF).
A few years ago, you would simply change the URL to http://169.254.169.254/latest/meta-data/iam/security-credentials/, dump the AWS keys, and submit a Critical severity report. But today, you try that, and the server returns a 401 Unauthorized or simply times out.
Welcome to 2026. The easy SSRF bugs are dead, killed by Instance Metadata Service Version 2 (IMDSv2). But as authorized testers and defenders know, the cloud metadata attack surface is far from secure if you know where to look.
The Goal & Scope Rules
This methodology is designed for authorized penetration testing and bug bounty hunting. The objective is to identify blind and non-blind SSRF vulnerabilities and attempt to escalate them to cloud identity compromise (accessing IAM roles via metadata services).
Scope Reminder: Never use these techniques to exfiltrate actual customer data or modify cloud infrastructure. If you extract AWS credentials during an authorized test, validate them using aws sts get-caller-identity to prove impact, then immediately stop and report.
Stage 1: The IMDSv2 Barrier
AWS introduced IMDSv2 specifically to neutralize standard GET-based SSRF attacks.
To retrieve metadata under IMDSv2, you cannot just send a GET request. The application must first perform a PUT request with a specific header to obtain a session token, and then include that token in subsequent GET requests.
Most basic SSRF vulnerabilities in web applications only permit you to dictate the URL, forcing the server to make a simple GET request. If you cannot inject headers or change the HTTP method to PUT, you cannot bypass a properly configured IMDSv2 environment.
A typical architecture diagram showing how an authorized tester leverages a "power-user" SSRF vulnerability to inject headers, bypassing IMDSv2 restrictions to reach the metadata service.
Stage 2: Hunting for "Power-User" SSRF
Because basic GET SSRFs are largely dead-ends in modern clouds, our methodology must shift toward finding "Power-User" SSRFs. These are vulnerabilities where the application allows us to coerce complex requests.
Target 1: Custom HTTP Clients and Webhooks
Look for webhook integrations or API testing features. Some modern applications (especially those built for developers) use HTTP clients that parse headers directly from your input.
If you find a JSON payload like this:
{ "webhook_url": "http://example.com", "method": "POST" }
Try changing the method and injecting headers. You might be able to construct the exact request IMDSv2 requires:
{ "webhook_url": "http://169.254.169.254/latest/api/token", "method": "PUT", "headers": { "X-aws-ec2-metadata-token-ttl-seconds": "21600" } }
Target 2: AI and Agentic Frameworks
As we covered in our recent Autonomous AI Agents research, AI inference toolkits and agentic frameworks often act as highly privileged proxies. If you can use prompt injection to instruct an AI agent to use its "Web Fetch Tool," you can often specify headers and methods, effectively bypassing the web application's standard SSRF filters.
Stage 3: Protocol Smuggling & Alternate Targets
If you are stuck with a strict GET request, look for protocol smuggling opportunities.
If the application uses a vulnerable version of cURL under the hood, or if you can control the protocol scheme, try using gopher:// or dict://. The Gopher protocol allows you to dictate the exact bytes sent over a TCP connection, enabling you to manually construct the PUT request, followed by the GET request, within a single payload.
Pivoting to Internal Services
If IMDSv2 is strictly enforced and you cannot inject headers, stop banging your head against the wall and pivot. The metadata service isn't the only valuable target.
Use the SSRF to scan the internal network (10.0.0.0/8, 172.16.0.0/12) for unauthenticated internal services:
- Redis (
port 6379) - Elasticsearch (
port 9200) - Kubernetes API (
port 10250,8443)
A simple GET request to an unauthenticated internal Elasticsearch cluster often yields API keys, database credentials, or customer PII, resulting in the same Critical severity payout without ever touching the metadata service.
Common Mistakes
- Assuming IMDSv2 is Everywhere: Always test for IMDSv1 first. Many organizations enforce IMDSv2 on their primary web clusters but forget to enforce it on legacy microservices, background job runners, or staging environments. Always attempt a direct
GETtohttp://169.254.169.254/latest/meta-data/. - Ignoring the Identity Context: Finding the SSRF is only step one. If you extract credentials, you must figure out what that IAM role can actually do. An SSRF that yields a role with no permissions is a low-severity bug. An SSRF that yields a role capable of reading production S3 buckets is a critical finding.
How Defenders Catch This
Defenders are increasingly moving away from simple WAF rules (which are easily bypassed using techniques like DNS Rebinding) and toward identity-based controls.
Modern cloud security relies on VPC Endpoint Policies and IAM Condition Keys. A robust defensive setup will use aws:SourceIp or aws:SourceVpc condition keys to ensure that even if an attacker steals the metadata credentials via SSRF, those credentials cannot be used from an external IP address (the attacker's machine).
References / Further reading
- Bypassing IMDSv2 Restrictions - AppSecure - https://appsecure.security/research/imdsv2-bypass-ssrf
- Cloud Metadata Security Best Practices - Cloud Security Alliance - https://cloudsecurityalliance.org/research/cloud-metadata
- Advanced DNS Rebinding Techniques - Vectra AI - https://vectra.ai/research/dns-rebinding-ssrf
- Red Teaming Cloud Infrastructure - HackDB - https://hackdb.com/cloud-red-teaming
