0xNULLBYTE
monitoring · 2026-05-15
← back to index
METHODOLOGY 08 FEB 2026 · 13 min read

The SSRF Hunter's Field Manual

A working playbook for finding, escalating, and reporting Server-Side Request Forgery in the wild.

FILED BY zvenden10

There are flashier vulnerabilities than SSRF, but few are as reliably profitable. Cloud-native architecture multiplied the blast radius by an order of magnitude, and developers keep building features that fetch URLs on behalf of users. The bug class is not going anywhere.

Where SSRF lives

Anywhere the server makes an HTTP request based on user input. The interesting part is where you find that pattern hiding. My priority list, in order of average bounty:

  • Webhook configuration. Slack-clones, CI integrations, payment providers. The user supplies a URL to "receive notifications," and the server happily POSTs to it.
  • URL preview / unfurl. Chat apps, social platforms, email tools that fetch a URL and render its OG metadata.
  • PDF / screenshot generators. A headless browser fetching content based on user-supplied URLs is a juicy target — bonus points if it executes JavaScript.
  • Image proxies / avatar uploaders. "Import from URL" features.
  • RSS / Atom / OPML importers. Forgotten endpoints, often unauthenticated.
  • OAuth / OIDC discovery. Configurable identity provider URLs that the server fetches metadata from.
  • XML parsers. XXE is SSRF's older sibling and still alive in legacy enterprise software.

Bypassing the easy filters

Most apps these days have some kind of allowlist or blocklist. They are almost always wrong. A working bypass kit:

# Decimal IP encoding
http://2130706433/        → 127.0.0.1

# Octal
http://0177.0.0.1/        → 127.0.0.1

# IPv6 mapped
http://[::ffff:127.0.0.1]/

# Rare but still works
http://127.1/
http://127.0.0.1.nip.io/

# DNS rebinding (most powerful)
# Attacker-controlled DNS that resolves
# first to 8.8.8.8, then 169.254.169.254
# between the validation check and the fetch.

# Redirect chains
attacker.com/r → 302 → http://169.254.169.254/

# URL parsing differentials
http://allowed-host.com#@evil.com/
http://allowed-host.com\@evil.com/
http://evil.com\@allowed-host.com/

Test every payload against the actual fetch behavior. The string parser, the DNS resolver, and the HTTP client may disagree, and disagreement is the attack.

The cloud metadata jackpot

If the target runs on a major cloud, the highest-value SSRF target is the instance metadata service:

  • AWS: 169.254.169.254/latest/meta-data/iam/security-credentials/ (IMDSv1, if enabled, returns temporary creds with no auth).
  • GCP: metadata.google.internal/computeMetadata/v1/ with the Metadata-Flavor: Google header — possible if the SSRF lets you control headers.
  • Azure: 169.254.169.254/metadata/identity/oauth2/token with an api-version param.

An IAM credential pulled from IMDSv1 is, in many cases, equivalent to taking over the entire AWS account. This is the difference between a $500 report and a $20,000 one. Take the time to chain.

Blind SSRF: when there's no response

Sometimes the app makes the request but never shows you the result. That's still a vulnerability — and often a more interesting one because it implies internal-only services.

  • Use a unique out-of-band domain per test (Burp Collaborator, interactsh, your own DNS).
  • Watch for DNS resolution as the cheapest signal: it works through HTTPS-only restrictions and most proxies.
  • Time the differences. localhost port-scanning via response time still works in 2026.
  • If you can chain to internal HTTP services, look for unauthenticated admin panels — Redis, Memcached, Elasticsearch, internal Jenkins, Prometheus, Consul.

The Gopher trick

If the underlying HTTP library supports gopher:// (some versions of curl do, in PHP), you can craft arbitrary TCP payloads. This is how blind SSRF turns into Redis RCE: send a CRLF-injected gopher payload that writes a cron job, get a shell. Worth checking for; rare to find in 2026 but spectacular when you do.

Writing the report that gets paid

Triagers reject SSRF reports all day for one reason: no demonstrated impact. "I can make the server fetch a URL" is not a vulnerability — it's a feature. What you need:

  1. Concrete internal access. A screenshot of the metadata endpoint, an internal hostname that resolves, a port that responds.
  2. A clear escalation path. "If this server is on AWS, this returns IAM creds for the role X" beats "this is exploitable."
  3. A working PoC. Curl command, request file, video if you must. Make it idempotent.
  4. Mitigation that the team can actually implement. Suggest IMDSv2, allowlists, network segmentation. Be useful.

SSRF is a craft. The bypass list above gets you in the door; the rest is patience, methodical enumeration, and writing reports that read like internal incident reviews. Hunt accordingly.