CVE-2026-77775: Headroom LLM Proxy SSRF Vulnerability

CVE-2026-77775 Overview

CVE-2026-77775 is a Server-Side Request Forgery (SSRF) vulnerability [CWE-918] in the Headroom LLM proxy. The proxy accepts a client-supplied x-headroom-base-url request header and uses it as the upstream destination without validating the address. Attackers can direct proxy traffic to loopback, link-local, and RFC 1918 destinations, including cloud instance metadata endpoints. Because the proxy returns the upstream response to the caller, internal service data and metadata are disclosed. The Authorization header is also forwarded unchanged to the attacker-designated host.

Critical Impact
Unauthenticated network attackers can reach internal services and cloud metadata endpoints through the proxy and exfiltrate forwarded credentials.

Affected Products

Headroom LLM proxy (repository headroomlabs-ai/headroom)
Reference deployments using the shipped docker-compose.yml with --host 0.0.0.0
Versions prior to the upstream_guard fix introduced at v0.36.1

Discovery Timeline

2026-08-21 - CVE CVE-2026-77775 published to NVD
2026-08-21 - Last updated in NVD database

Technical Details for CVE-2026-77775

Vulnerability Analysis

The Headroom proxy exposes two code paths that read the client-controlled x-headroom-base-url header. The function _resolve_openai_upstream_base in headroom/proxy/handlers/openai.py accepts the header, requires only that it parse as a URL with an http or https scheme and a hostname, and returns it as the upstream base. The function _select_passthrough_base_url in headroom/providers/proxy_routes.py reads the same header for the passthrough routes.

Because Headroom is a forwarding proxy, upstream responses are returned to the caller. An attacker can therefore read the body of any HTTP service the proxy host can reach. This includes AWS, GCP, and Azure instance metadata endpoints, internal admin APIs, and services bound to loopback.

Root Cause

The root cause is missing destination validation on caller-supplied URLs. Neither handler rejects loopback addresses (127.0.0.0/8), link-local ranges (169.254.0.0/16, including 169.254.169.254), or RFC 1918 private ranges. The Authorization header submitted by the caller is forwarded unchanged to the attacker-designated host, leaking any bearer token attached to the request.

Attack Vector

The pip console script binds 127.0.0.1 by default, but the shipped docker-compose.yml runs the server with --host 0.0.0.0, publishes ports, and does not require HEADROOM_PROXY_TOKEN. The server logs a startup warning about this configuration, yet the compose file remains the reference deployment. A remote, unauthenticated attacker sends an HTTP request to the exposed proxy port with x-headroom-base-url set to an internal or metadata URL. The proxy forwards the request, and the response body is returned to the attacker. See the VulnCheck Advisory on Headroom Proxy for full technical detail.

Detection Methods for CVE-2026-77775

Indicators of Compromise

Inbound HTTP requests to the Headroom proxy containing the x-headroom-base-url header with values referencing 127.0.0.1, localhost, 169.254.169.254, metadata.google.internal, or RFC 1918 addresses.
Outbound proxy connections from the Headroom container to cloud metadata endpoints or internal service IPs not previously observed.
Proxy access logs missing HEADROOM_PROXY_TOKEN authentication and originating from untrusted networks.

Detection Strategies

Inspect reverse proxy or load balancer logs for requests to Headroom endpoints that carry the x-headroom-base-url header.
Alert on any Headroom container egress to link-local address 169.254.169.254 or private RFC 1918 ranges.
Correlate startup log warnings about missing HEADROOM_PROXY_TOKEN with externally reachable listener sockets.

Monitoring Recommendations

Capture and retain full HTTP request headers on the ingress path in front of the proxy for retrospective hunting.
Baseline expected upstream destinations for the Headroom proxy and alert on deviations.
Monitor cloud provider metadata endpoint access from workload identities running Headroom.

How to Mitigate CVE-2026-77775

Immediate Actions Required

Upgrade to Headroom v0.36.1 or later, which introduces the upstream guard code that validates upstream destinations.
Remove --host 0.0.0.0 from the deployed docker-compose.yml unless the proxy sits behind an authenticated ingress.
Set HEADROOM_PROXY_TOKEN to a strong secret and require it on all data-plane routes.
Rotate any bearer tokens or API keys that clients previously forwarded through the proxy.

Patch Information

The fix is tracked in Pull Request #2207 and shipped in v0.36.1. The new upstream_guard module rejects loopback, link-local, and private destinations before the proxy forwards a request. Review the OpenAI handler source to confirm which version your deployment runs.

Workarounds

Bind the proxy to 127.0.0.1 and place it behind an authenticated reverse proxy that strips the x-headroom-base-url header from untrusted callers.
Block egress from the Headroom host to 169.254.169.254 and other metadata endpoints using host firewall rules or cloud security groups.
Enforce IMDSv2 session tokens on AWS instances to reduce impact of metadata SSRF.

bash

# Configuration example: strip the vulnerable header at an nginx ingress
location / {
    proxy_set_header x-headroom-base-url "";
    proxy_pass http://127.0.0.1:8000;
}