Headroom: client-supplied x-headroom-user-id header is trusted as identity, exposing other users' memory

Impact

The proxy reads the memory owner straight from the x-headroom-user-id request header on the chat-completion and websocket paths, and nothing binds that value to the caller. A client can name someone else's identifier and read or write that user's stored LLM memory. The shipped docker-compose makes this reachable from the network rather than loopback: it runs the server with --host 0.0.0.0, publishes the ports, and does not require HEADROOM_PROXY_TOKEN, a combination the server itself warns about at startup. Anyone running the reference compose file on a shared box has an unauthenticated cross-user data plane, and stored memory is exactly where prompts, context and pasted credentials accumulate.

Who can reach it

Any network client that can reach the published proxy port when deployed from the reference docker-compose, with no authentication. The pip console script binds 127.0.0.1 by default, so a plain local install limits this to local callers.

What to do

Upgrade to a release carrying the resolve_memory_identity seam in headroom/proxy/identity.py (present in v0.36.1), which honors the header only for loopback or allowlisted callers and otherwise binds identity to the proxy-token fingerprint or the OS user, then restart the proxy. If you deployed the shipped compose file, also set HEADROOM_PROXY_TOKEN and stop publishing the port to anything wider than loopback - the compose defaults are the reason this is remotely reachable at all.

References