Headroom's LLM proxy derives the memory owner from the x-headroom-user-id request header, which is read directly in multiple request handlers without verifying the caller's identity. This lack of binding allows clients to specify arbitrary user IDs and access or modify other users' stored LLM memory. The intended fix introduces a resolve_memory_identity function that restricts honoring the header to loopback or allowlisted callers and otherwise binds identity to the proxy-token fingerprint or OS user. However, the default docker-compose deployment binds to 0.0.0.0 with no required authentication token, exposing the vulnerable data-plane routes to the network.

An unauthenticated remote attacker can bypass authorization controls by spoofing the x-headroom-user-id header, enabling them to read or write another user's stored LLM memory. This leads to a complete confidentiality and integrity compromise of user memory data. The vulnerability does not impact availability. The CVSS 3.1 base score is 9.1 (critical), reflecting network attack vector, low attack complexity, no privileges required, no user interaction, and high confidentiality and integrity impact.

Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. The vendor's intended fix restricts honoring the x-headroom-user-id header to trusted callers and binds identity to authenticated tokens or OS users. Until an official fix is available, avoid deploying the service bound to 0.0.0.0 without authentication tokens. Prefer binding to localhost (127.0.0.1) or implementing strict network access controls and requiring HEADROOM_PROXY_TOKEN authentication to prevent unauthorized access.