This CVE is worse than its CVSS 8.6 suggests. The SSRF via x-headroom-base-url is real, but the compound failure is what makes this severe: the reference deployment ships with authentication optional, binds to 0.0.0.0, and forwards the Authorization header to the attacker-controlled upstream. You're not getting SSRF—you're getting a credential relay to everything that trusts the proxy's token.
If HEADROOM_PROXY_TOKEN isn't set (the default), the server logs a warning at startup and continues running. That warning is architecturally significant: it's a liability document, not a guardrail. It creates documentary evidence that the project knew about the risk while simultaneously enabling exploitation. Developers trained to bypass warnings that don't block operation will bypass this one.
The LLM proxy context dramatically widens the blast radius. The Authorization header here isn't a service credential—it's likely a provider API key with access to model fine-tuning, embeddings, training pipelines, and cost management. Traditional SSRF is bounded by what the internal service returns. This is bounded by what the LLM token can access, which often includes systems never designed to sit behind an unauthenticated proxy.
Check your deployment now: verify HEADROOM_PROXY_TOKEN is set and enforced, confirm the service isn't binding to 0.0.0.0 on exposed ports, and audit what Authorization headers are being forwarded. If you're running the reference docker-compose.yml as-shipped, you're exposed. The fix isn't just patching the header handling—it's treating authentication as load-bearing, not optional, and refusing to start without it.