SSRF Beyond AWS: GCP, Azure, On-Prem and DNS Rebinding

Last updated: April 26, 2026

SSRF (Server-Side Request Forgery) is the vulnerability where an attacker makes the server fetch a URL on their behalf. Most articles focus on AWS metadata extraction. The actual SSRF attack surface in 2026 is broader — GCP and Azure metadata endpoints, on-prem internal services, third-party SaaS reaching back into AWS, DNS rebinding bypasses. This article covers SSRF beyond AWS and the architectural defences that close every variant.

The cloud metadata endpoints

Test all of them when you find SSRF. Indian companies often run multi-cloud; one application may live in AWS but call services in Azure or GCP, and the SSRF reach extends accordingly.

On-prem internal services

SSRF inside corporate networks reaches:

• Internal admin panels on http://localhost:8080, http://10.0.x.x, http://192.168.x.x ranges
• Service discovery / Consul / etcd on default ports
• Redis on 6379, MongoDB on 27017 — services commonly bound to localhost without auth
• Internal Jenkins, Jira, Confluence — often less-protected than public-facing apps
• Kubernetes API on 10250 (kubelet) or 8080 (insecure API)
• Elasticsearch on 9200 — historically wide open

The classic SSRF + Redis combination: SSRF lets you send Redis commands to the internal Redis; Redis CONFIG SET / SAVE writes a webshell to the web server’s directory; remote code execution achieved.

DNS rebinding bypass

If the application validates URLs by resolving the hostname and checking for private IPs, attackers use DNS rebinding:

1. Attacker registers attacker.com with a controlled DNS server
2. DNS server returns public IP for the first resolution (passes URL validation)
3. On second resolution (during the actual fetch), DNS returns 169.254.169.254 or 10.0.0.1
4. Application fetches the internal URL believing it had validated the destination

Defence: validate at fetch-time, not validation-time, or use a fetch library that resolves once and uses that IP for the entire request.

Other bypasses

• URL parsing inconsistency — application parses URL one way, fetch library another. Examples: http://attacker.com#@169.254.169.254/ — some parsers see attacker.com, some see 169.254.169.254.
• Decimal IP encoding — http://2852039166/ equals http://169.254.169.254/. Some validators only check for dotted-quad format.
• IPv6 alternatives — http://[::ffff:169.254.169.254]/, http://[fd00:ec2::254]/ on AWS, http://[fe80::a9fe:a9fe]/.
• Redirects — application validates direct URL but follows redirects without re-validating.
• Gopher protocol — gopher:// URLs let you craft arbitrary TCP payloads. Use to interact with non-HTTP services (Redis, MySQL, SMTP) via SSRF.

How to test for SSRF

1. Identify any place URL or domain input is accepted: image fetchers, webhook configurations, profile imports, RSS readers, PDF generators, OAuth callback handlers, link previewers.
2. Test cloud metadata endpoints (all major clouds).
3. Test localhost, internal IP ranges (RFC 1918).
4. Test DNS rebinding via rbndr.us or your own controlled DNS.
5. Test URL parser bypasses.
6. Test gopher:// for protocol smuggling.
7. Burp Collaborator for blind SSRF detection — if your collaborator gets a request, the SSRF is confirmed.

Detection — what works

• Egress filtering at VPC / network level — block outbound connections from application servers to RFC 1918 internal addresses, except specific allow-listed destinations.
• Block metadata endpoints from application networks at firewall layer, unless legitimate need.
• SSRF-aware WAF rules — block requests with metadata IPs, internal IPs, decimal-IP encoding in URL params.
• Application logs for outbound HTTP requests with anomalous destinations.

The architectural fix

• Allow-list destination domains — applications fetching URLs should specify exactly which domains are permitted. Anything else is rejected.
• Use a separate egress proxy — application traffic flows through a proxy that enforces destination policy.
• Block private IP ranges at the proxy — even if URL validation is bypassed, the proxy refuses to connect to RFC 1918.
• Enforce IMDSv2 / Metadata-Flavor headers on cloud workloads — basic SSRFs cannot send required headers.
• Bind internal services to localhost only where possible; require explicit network policies for inter-service communication.

How to find your next SSRF

• Map every URL-input field in the application. Each is a candidate.
• Test multi-cloud metadata endpoints.
• Test internal service ports — Redis, MongoDB, Elasticsearch, Kubernetes API.
• If basic IPv4 metadata fails, test IPv6 alternatives, decimal encoding, DNS rebinding.

Compliance angle

• OWASP Top 10 A10:2021 — Server-Side Request Forgery is its own top-10 category since 2021.
• DPDP §8(5) — SSRF allowing internal-service compromise is a defensible-security failure.
• SEBI CSCRF — application security testing must cover SSRF.

The takeaway

SSRF is broader than AWS metadata extraction. Multi-cloud environments, internal services, and DNS rebinding extend the attack surface significantly. The fix is allow-list-based egress at the network layer plus IMDSv2 enforcement. Run Burp Collaborator against every URL-input field in your application; the surprises are usually waiting.