CVE-2026-77775 is a high severity server-side request forgery flaw in the Headroom LLM proxy. A client can pick the upstream address with a request header, and responses come back to the caller. VulnCheck lists versions before 0.36.1 as affected. Upgrade, set a proxy token and keep the proxy off open networks.
What's affected
Headroom (headroomlabs-ai) versions before 0.36.1, according to the VulnCheck advisory. The advisory references a guard module present in v0.36.1 and the code at v0.29.0 as the vulnerable reference point.
Severity conflict: the record scores this 8.6 high (CVSS 3.1). VulnCheck lists it as high with a score of 7.7 alongside a CVSS 4.0 vector. Both say high. Use whichever scoring system your policy follows.
Exposure depends on deployment. VulnCheck says the pip console script binds to 127.0.0.1 by default, but the reference docker-compose.yml ships with host 0.0.0.0, published ports and no required proxy token, so a deployment that follows the shipped compose file is reachable from the network without authentication.
How to check if you're exposed
Check the installed version, then check how the proxy is exposed.
pip show headroom
docker compose config | grep -i -E "host|HEADROOM_PROXY_TOKEN|ports"
The package name may differ in your install, so confirm it against the project's documentation. Then test reachability from another machine on your network: if the proxy answers, anyone on that network can use its data-plane routes. Review whether HEADROOM_PROXY_TOKEN is set.
What to do now
- Upgrade Headroom to 0.36.1 or later.
- Set HEADROOM_PROXY_TOKEN so the data-plane routes require authentication, and bind the proxy to 127.0.0.1 unless you need remote access.
- Block the proxy host from reaching loopback, link-local metadata addresses and private ranges at the network layer.
- Rotate any API keys that passed through an exposed proxy. The advisory says the Authorization header is forwarded to whatever host the caller names.
Why it matters
This is CWE-918, server-side request forgery. The proxy exists to forward calls to an LLM provider, and it let the client override the destination with the x-headroom-base-url header. The only check was that the value parsed as an http or https URL with a hostname. Loopback, link-local and private addresses were accepted.
Two things make a proxy SSRF worse than a typical one. The upstream response is returned to the caller, so internal services and cloud metadata addresses can be read in full. And the Authorization header travels with the request, so credentials meant for a provider can end up at an address the caller chose. The record shows no KEV listing, and the sources report no exploitation.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Am I safe if the proxy only listens on localhost?
Much safer, since remote callers cannot reach it. Anything else on that machine that can send it requests could still use the header.
Why does the proxy header matter for keys?
The advisory says the caller's Authorization header is passed to the host named in the base URL header, which can be a host the attacker controls.
Sources
Last reviewed: 18 October 2026.
