Headroom
Monthly
Cross-origin WebSocket hijacking in Headroom's proxy layer (prior to v0.35.0) allows an unauthenticated attacker-controlled webpage to issue arbitrary LLM requests through the victim's Headroom instance without authentication. Because the WebSocket server forwards requests to the upstream LLM provider without validating the Origin header, any browser with network access to the proxy-standard or headless-can be weaponized as a relay. The primary concrete impact is unauthorized consumption of the stored OpenAI API key and potential exposure of LLM response content; no public exploit code or CISA KEV listing has been identified at time of analysis.
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-origin WebSocket hijacking in Headroom's proxy layer (prior to v0.35.0) allows an unauthenticated attacker-controlled webpage to issue arbitrary LLM requests through the victim's Headroom instance without authentication. Because the WebSocket server forwards requests to the upstream LLM provider without validating the Origin header, any browser with network access to the proxy-standard or headless-can be weaponized as a relay. The primary concrete impact is unauthorized consumption of the stored OpenAI API key and potential exposure of LLM response content; no public exploit code or CISA KEV listing has been identified at time of analysis.
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.