Headroom vulnerabilities

Prior to version 0.35.0, the Headroom WebSocket server does not validate the `Origin` header of incoming client WebSocket requests before forwarding the request to the upstream server, allowing malicious WebSocket clients to perform arbitrary LLM requests without authentication. This can be exploited by a malicious WebSocket client executed in a traditional or headless browser if the browser has access to the Headroom proxy and the OpenAI API key is stored in the `OPENAI_API_KEY` environment variable. Version 0.35.0 fixes the issue.

Headroom's LLM proxy derives the memory owner from the x-headroom-user-id request header. The header is read directly at several points, and nothing binds the value to the caller. A client can name another user's identifier and read or write that user's stored LLM memory. The fix introduces a single resolve_memory_identity seam that honors the header only for loopback or allowlisted callers and otherwise binds the identity to the proxy-token fingerprint or the operating system user. The pip console script binds 127.0.0.1 by default, but the reference docker-compose.yml ships --host 0.0.0.0 with published ports and no required HEADROOM_PROXY_TOKEN, exposing the affected data-plane routes to the network without authentication.

Headroom's LLM proxy lets a client choose the upstream destination with the x-headroom-base-url request header. No check rejects loopback, link-local, or RFC 1918 destinations, so requests reach internal services and cloud metadata addresses. The Authorization header is forwarded unchanged to the caller-designated host. The reference docker-compose.yml exposes ports without required token, increasing risk.