Headroom EUVD-2026-63904

Exploitation against the default docker-compose deployment requires no special conditions: the reference docker-compose.yml binds 0.0.0.0 and ships without a required HEADROOM_PROXY_TOKEN, so any host with network connectivity to the published port can send the crafted header. The proxy routes that are affected are the OpenAI-compatible data-plane routes and passthrough routes. For pip-installed deployments (non-Docker), the server defaults to binding 127.0.0.1, limiting exploitation to processes on the same host. Exploitation is further limited to services reachable from the proxy host's network namespace - cloud metadata endpoints (169.254.169.254) are reachable only from cloud-hosted deployments, and internal service access is scoped to the proxy host's network. Authorization header forwarding to attacker-controlled hosts requires an active client session with a bearer token to be in-flight. No privileged access, special configuration flag, or specific Headroom feature toggle beyond the default deployment is required for the SSRF condition itself.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/SC:H) assigns a 7.7 score reflecting network-accessible, zero-complexity, unauthenticated exploitation with high confidentiality impact on subsequent systems - an accurate characterization for docker-compose deployments. The critical aggravating factor beyond the CVSS score is Authorization header forwarding: an attacker can harvest API keys or bearer tokens passed by legitimate clients by designating an attacker-controlled host. Real-world risk is highly deployment-dependent: the pip console script defaults to 127.0.0.1 binding, confining the attack surface to local clients; however, the vendor-shipped docker-compose.yml overrides this to 0.0.0.0 and sets no HEADROOM_PROXY_TOKEN, exposing the data-plane globally on the published port. Organizations following the quickstart guide are therefore vulnerable without any misconfiguration on their part. No EPSS score or KEV listing is available in the provided data, so exploitation frequency cannot be quantified from signals beyond the vulnerability mechanics; the low product prevalence moderates aggregate real-world exposure but does not reduce per-instance risk for affected deployments.

An attacker with network access to an internet-exposed Headroom instance running with the default docker-compose configuration sends a single HTTP request to a proxy data-plane route with the header x-headroom-base-url: http://169.254.169.254/latest/meta-data/iam/security-credentials/; the proxy fetches that URL from the EC2 instance metadata service and returns the IAM role credentials in the response body. In a second pass, the attacker replaces the base URL with an attacker-controlled server, then triggers a request from a legitimate client - the client's Authorization bearer token is forwarded to the attacker's server, yielding API credentials. No public exploit code has been identified, but the attack requires only standard HTTP client tooling and knowledge of the header name.