Headroom LLM proxy: client-chosen upstream base URL enables SSRF and leaks the Authorization header

Impact

A caller sets the x-headroom-base-url header and the proxy forwards the request to any host that parses as http/https with a hostname - loopback, link-local, and RFC 1918 addresses are not rejected. Because the component is a proxy, the upstream response body comes back to the caller, so internal services and cloud instance-metadata endpoints on a GPU node are readable through it. The Authorization header travelling with the request is forwarded unchanged to the attacker-designated host, handing over whatever API key the caller supplied or the deployment injected. On a fleet where the proxy sits alongside inference workloads, that is a pivot from the model-serving data plane into the cluster's internal HTTP surface and its credentials.

Who can reach it

Anyone who can reach the proxy's data-plane routes. The pip console script binds 127.0.0.1, but the shipped docker-compose.yml runs --host 0.0.0.0 with published ports and no required HEADROOM_PROXY_TOKEN, so a deployment following the reference compose is exposed unauthenticated to the network.

What to do

Upgrade to a build containing the upstream address validation (the record shows headroom/proxy/upstream_guard.py present at v0.36.1 and PR 2207); the advisory in this record does not name a fixed release, so confirm against the vendor before scheduling. Until then, set HEADROOM_PROXY_TOKEN, stop publishing the container port, and bind the proxy back to loopback or a restricted network. The change is a container image bump and proxy restart - no node drain, but in-flight inference requests through the proxy are dropped.

References