Headroom
Monthly
Cross-user memory disclosure and tampering in Headroom's LLM proxy (versions before 0.36.1) lets a caller read or overwrite any user's stored LLM memory by simply naming another user's identifier in the client-supplied x-headroom-user-id request header. The proxy trusts this header as the authenticated identity across the chat-completion and websocket data-plane paths in headroom/proxy/handlers/openai.py, with nothing binding the value to the actual caller. The console script binds loopback by default, but the shipped docker-compose.yml publishes the proxy on 0.0.0.0 with no required proxy token, so a stock Docker deployment exposes these routes to the network unauthenticated. Reported by VulnCheck; no public exploit identified at time of analysis.
Server-side request forgery in Headroom LLM proxy (versions before 0.36.1) allows unauthenticated remote attackers to redirect proxy upstream requests to arbitrary internal, loopback, link-local, or RFC 1918 destinations - including cloud instance metadata endpoints such as 169.254.169.254 - by supplying a crafted x-headroom-base-url request header. The proxy returns upstream responses verbatim to the caller, disclosing internal service content; critically, it also forwards the original Authorization header to the attacker-designated host, enabling credential harvesting. Exploitation is trivially achievable against deployments using the vendor-shipped docker-compose.yml, which binds 0.0.0.0 and enforces no HEADROOM_PROXY_TOKEN by default - a configuration weakness the server itself warns about at startup. No public exploit or KEV listing is identified at time of analysis; a vendor patch is available in v0.36.1.
Cross-user memory disclosure and tampering in Headroom's LLM proxy (versions before 0.36.1) lets a caller read or overwrite any user's stored LLM memory by simply naming another user's identifier in the client-supplied x-headroom-user-id request header. The proxy trusts this header as the authenticated identity across the chat-completion and websocket data-plane paths in headroom/proxy/handlers/openai.py, with nothing binding the value to the actual caller. The console script binds loopback by default, but the shipped docker-compose.yml publishes the proxy on 0.0.0.0 with no required proxy token, so a stock Docker deployment exposes these routes to the network unauthenticated. Reported by VulnCheck; no public exploit identified at time of analysis.
Server-side request forgery in Headroom LLM proxy (versions before 0.36.1) allows unauthenticated remote attackers to redirect proxy upstream requests to arbitrary internal, loopback, link-local, or RFC 1918 destinations - including cloud instance metadata endpoints such as 169.254.169.254 - by supplying a crafted x-headroom-base-url request header. The proxy returns upstream responses verbatim to the caller, disclosing internal service content; critically, it also forwards the original Authorization header to the attacker-designated host, enabling credential harvesting. Exploitation is trivially achievable against deployments using the vendor-shipped docker-compose.yml, which binds 0.0.0.0 and enforces no HEADROOM_PROXY_TOKEN by default - a configuration weakness the server itself warns about at startup. No public exploit or KEV listing is identified at time of analysis; a vendor patch is available in v0.36.1.