Back to Insights
June 06, 2026 4.295 min read SSRF Cloud Security AWS

Chaining SSRF to Internal Metadata Access

APIVAPT Research Team Offensive Security

Introduction

Server-Side Request Forgery (SSRF) is often underestimated. On its own, it may seem like a low-severity issue — the ability to make a server fetch an arbitrary URL. But in cloud environments, SSRF becomes the first link in a devastating attack chain that can lead to full infrastructure compromise.

The Anatomy of SSRF

SSRF occurs when an application fetches a URL provided by the user without proper validation:

# Vulnerable endpoint
@app.route('/api/preview')
def preview():
    url = request.args.get('url')
    response = requests.get(url)  # No validation!
    return response.text

An attacker can abuse this to access internal resources that are normally unreachable from the internet.

Cloud Metadata: The Crown Jewels

Every major cloud provider exposes an instance metadata service at a well-known internal IP:

Provider Metadata Endpoint
AWS http://169.254.169.254/latest/meta-data/
GCP http://metadata.google.internal/computeMetadata/v1/
Azure http://169.254.169.254/metadata/instance

These endpoints expose: - IAM credentials with potentially broad permissions - Instance identity tokens for service-to-service authentication - User data scripts that may contain secrets - Network configuration revealing internal architecture

The Attack Chain

Step 1: Identify SSRF

We test API endpoints that accept URLs — webhooks, file imports, URL previews, PDF generators, and image processors.

Step 2: Bypass Filters

Common SSRF filters can be bypassed using: - DNS rebinding: Register a domain that alternates between a public IP and 169.254.169.254 - URL encoding: http://169.254.169.254http://0xa9fea9fe - Redirect chains: Host a page that 302-redirects to the metadata endpoint - IPv6 mapping: http://[::ffff:169.254.169.254]/

Step 3: Harvest Credentials

# Via SSRF, access AWS temporary credentials
GET /api/preview?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/my-role

Response:

{
  "AccessKeyId": "ASIA...",
  "SecretAccessKey": "wJalr...",
  "Token": "FwoGZX...",
  "Expiration": "2026-01-28T12:00:00Z"
}

Step 4: Lateral Movement

With harvested credentials, we can: - Access S3 buckets containing backups and sensitive data - Read secrets from AWS Secrets Manager or Parameter Store - Invoke Lambda functions or modify infrastructure - Pivot to other services within the VPC

Prevention

  1. Disable metadata v1 — Use IMDSv2 (token-required) on AWS
  2. Network-level controls — Block outbound requests to 169.254.169.254 from application containers
  3. URL validation — Allowlist permitted domains and protocols; resolve DNS before fetching to prevent rebinding
  4. Least-privilege IAM — Instance roles should have minimal permissions
  5. Monitor metadata access — Alert on unusual metadata API calls

Conclusion

SSRF in a cloud environment is not a "medium" finding — it's a critical path to total compromise. The chain from "fetch this URL" to "here are your AWS credentials" can be executed in minutes by a skilled attacker. This is exactly the type of multi-step, context-dependent vulnerability that automated scanners consistently miss.

Security Assessment

Ready to secure your systems?

Our team specialises in manual API penetration testing — finding the logic flaws automated scanners miss.