CVE-2026-77775

Headroom Proxy Sends Upstream Requests to a Client-Supplied Base URL Without Address Validation

Published Aug 21, 2026 CVSS 4.0 · 7.7 High EPSS < 1% KEV · Not listed
Description
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.

Analysis

AI-generated

Technical impact

Headroom's LLM proxy allows a client to specify an arbitrary upstream destination through the x-headroom-base-url request header. The implementation accepts any URL that parses as a valid http or https scheme and a hostname, without rejecting loopback, link‑local, or RFC 1918 addresses. This is a CWE‑918 vulnerability. The forwarded Authorization header and the unfiltered proxy response mean that requests can reach internal services, cloud metadata endpoints, and other sensitive systems, exposing their responses and potentially enabling an attacker to interact with or exploit those services.

Affected Systems

Headroom Labs' Headroom LLM proxy is affected. No version‑specific information is provided in the advisory, so all current releases prior to a fix are potentially vulnerable.

Risk and Exploitability

The CVSS base score of 7.7 indicates a high‑severity flaw. EPSS is not available, and the vulnerability is not listed in CISA KEV, but the lack of address validation and the default exposure of network ports mean that an attacker could exploit the proxy from any network location that reaches the service. The attack requires sending a crafted HTTP request containing the x-headroom-base-url header; no authentication is required when using the default docker‑compose configuration, so the risk to networks that inadvertently expose the proxy is significant.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Disable external exposure by binding the proxy to localhost or behind an authenticated reverse proxy.
  • Enable the HEADROOM_PROXY_TOKEN environment variable to enforce authentication on all requests.
  • Upgrade to a newer Headroom release that includes proper validation of the x-headroom-base-url header or configure the proxy to reject loopback, link‑local, and RFC 1918 destinations.

Generated by OpenCVE AI on August 21, 2026 at 12:56 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories available
History
Type Values Removed Values Added
First Time appeared Headroom Labs
Headroom Labs headroom
Vendors & Products Headroom Labs
Headroom Labs headroom
Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'yes', 'Exploitation': 'none', 'Technical Impact': 'partial'}, 'version': '2.0.3'}

Type Values Removed Values Added
Description 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.
Title Headroom Proxy Sends Upstream Requests to a Client-Supplied Base URL Without Address Validation
Weaknesses CWE-918
References
Metrics cvssV3_1

{'score': 8.6, 'vector': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N'}

cvssV4_0

{'score': 7.7, 'vector': 'CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:N/SA:N'}

Weaknesses
  • CWE-918

    Server-Side Request Forgery (SSRF)

Sources

Status
PUBLISHED
Assigner
VulnCheck
Published
Updated
Nov 8, 2026, 2:09 PM
Reserved
Aug 21, 2026, 11:09 AM
Status
Deferred
Published
Aug 21, 2026, 12:16 PM
Modified
Oct 15, 2026, 7:10 PM