CVE-2026-77775 in Headroom
Summary
by MITRE • 08/21/2026
Headroom's LLM proxy lets a client choose the upstream destination with the x-headroom-base-url request header. _resolve_openai_upstream_base in headroom/proxy/handlers/openai.py accepts the header value, requires only that it parse with an http or https scheme and a hostname, and returns it for use as the upstream base; _select_passthrough_base_url in headroom/providers/proxy_routes.py reads the same header for the passthrough routes. No check rejects loopback, link-local, or RFC 1918 destinations, and because the component is a proxy the upstream response is returned to the caller, so the request reaches internal services and cloud metadata addresses and their responses are disclosed. The Authorization header accompanying the request is forwarded unchanged to the caller-designated host. The pip console script binds 127.0.0.1 by default, but the reference docker-compose.yml ships --host 0.0.0.0 with published ports and no required HEADROOM_PROXY_TOKEN, which the server itself warns about at startup, so a deployment following the shipped compose exposes the affected data-plane routes to the network without authentication.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/21/2026
The vulnerability in Headroom's Large Language Model proxy constitutes a critical Server-Side Request Forgery (SSRF) flaw rooted in insufficient validation of user-supplied input within request routing logic. The core technical deficiency lies in the _resolve_openai_upstream_base function located in headroom/proxy/handlers/openai.py, which accepts the value from the x-headroom-base-url header and performs only a superficial check to ensure it parses as an HTTP or HTTPS scheme with a hostname. This validation fails to implement any restrictions against internal network ranges, loopback addresses, link-local interfaces, or RFC 1918 private IP spaces. Similarly, the _select_passthrough_base_url function in headroom/providers/proxy_routes.py exhibits identical lax behavior for passthrough routes. By allowing clients to dictate the upstream destination without sanitizing for local or internal targets, the proxy effectively acts as an open relay that can be directed to access resources within the host's own network perimeter or cloud provider metadata services.
The operational impact of this flaw is severe due to the proxy’s architecture and default deployment configurations. Because the component functions as a reverse proxy, it not only forwards the request but also returns the upstream response directly to the original caller. This mechanism enables an attacker to probe internal microservices, access sensitive configuration endpoints, or retrieve cloud instance metadata that typically contains credentials and security tokens. The risk is further amplified by the forwarding of the Authorization header unchanged to the designated host. If the target internal service requires authentication, the proxy inadvertently provides valid credentials from the original request context to unauthorized internal resources, facilitating privilege escalation or data exfiltration within the trusted network zone. This behavior aligns with CWE-918, which describes Server-Side Request Forgery where a web server makes requests on behalf of a client without proper validation of the target URL.
The severity is significantly heightened by common deployment practices that expose this vulnerability to unauthenticated attackers. While the pip console script defaults to binding only to 127.0.0.1, limiting exposure to local processes, the reference docker-compose.yml file ships with the --host flag set to 0.0.0.0 and published ports enabled by default. Crucially, this configuration does not enforce a required HEADROOM_PROXY_TOKEN for authentication on these data-plane routes. The server itself warns about the lack of authentication at startup, yet many deployments may ignore or overlook this warning during initial setup. Consequently, any host with network access to the proxy can exploit the SSRF vulnerability without needing valid credentials. This scenario maps directly to MITRE ATT&CK technique T1598, specifically Phishing for Inbound Credentials if exploited via social engineering, but more accurately reflects T1046 Network Service Discovery and T1537 Transfer Data to Cloud Account when used to exfiltrate data from cloud metadata endpoints.
To mitigate this vulnerability, immediate remediation steps must focus on strict input validation and network-level controls. The proxy code should be updated to explicitly reject any hostnames or IP addresses that resolve to loopback (127.0.0.0/8), link-local (169.254.0.0/16), private RFC 1918 ranges, and cloud metadata endpoints such as 169.254.169.254. Additionally, DNS rebinding protections should be implemented to prevent attackers from bypassing IP-based checks by resolving a hostname to an internal address after initial validation. From a deployment perspective, the docker-compose.yml configuration must be hardened by either binding strictly to 127.0.0.1 if external access is not required or enforcing strong authentication via HEADROOM_PROXY_TOKEN for all incoming requests on exposed ports. Network segmentation should also be employed to ensure that even if an SSRF attempt succeeds, the internal services are isolated from direct internet-facing entry points. These measures collectively address both the code-level logic flaw and the operational misconfiguration that currently exposes sensitive infrastructure components.