CVE-2026-77776

Headroom's LLM proxy determines which user's stored LLM memory to serve from the client-supplied x-headroom-user-id request header, reading it directly on the chat completion and websocket paths without binding the value to the actual caller (CWE-639, authorization bypass via user-controlled key). Any client that can reach the proxy can therefore send another user's identifier in that header and read or write that user's stored LLM memory. The pip console script binds to 127.0.0.1 by default, but deployments following the shipped docker-compose.yml run with --host 0.0.0.0, published ports, and no required HEADROOM_PROXY_TOKEN — a configuration the server itself warns about at startup — leaving the affected data-plane routes open to the network without authentication. The flaw affects confidentiality and integrity of stored user memory (CVSS 4.0 scores it 9.3 critical); no host-level or system-level impact is described. There is no public proof-of-concept, no CISA KEV listing, and EPSS is low at 0.3%, indicating no known exploitation to date.

What to do: Upgrade to the Headroom release containing the fix (the version adding the resolve_memory_identity seam in headroom/proxy/identity.py; no fixed version number was published in the disclosure data). If you run the shipped docker-compose.yml, set HEADROOM_PROXY_TOKEN or restrict network access to the published ports, since that configuration is unauthenticated and network-exposed. Audit whether your deployment binds 0.0.0.0 and whether external callers can set x-headroom-user-id, and until patching rely on loopback binding or allowlisting to limit exposure.