Headroom's LLM proxy derives the memory owner from the x-headroom-user-id request header. The header is read directly at several points in headroom/proxy/handlers/openai.py, including the chat completion and websocket paths, and nothing binds the value to the caller. A client can therefore name another user's identifier and read or write that user's stored LLM memory. The fix introduces a single resolve_memory_identity seam in headroom/proxy/identity.py 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, which the server itself warns about at startup, so a deployment following the shipped compose exposes the affected data-plane routes to the network without authentication.
Advisories
No advisories yet.
Fixes
Solution
No solution given by the vendor.
Workaround
No workaround given by the vendor.
References
History
Fri, 21 Aug 2026 13:00:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| First Time appeared |
Headroom Labs
Headroom Labs headroom |
|
| Vendors & Products |
Headroom Labs
Headroom Labs headroom |
Fri, 21 Aug 2026 11:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | Headroom's LLM proxy derives the memory owner from the x-headroom-user-id request header. The header is read directly at several points in headroom/proxy/handlers/openai.py, including the chat completion and websocket paths, and nothing binds the value to the caller. A client can therefore name another user's identifier and read or write that user's stored LLM memory. The fix introduces a single resolve_memory_identity seam in headroom/proxy/identity.py 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, which the server itself warns about at startup, so a deployment following the shipped compose exposes the affected data-plane routes to the network without authentication. | |
| Title | Headroom Proxy Treats the Client-Supplied x-headroom-user-id Header as an Authenticated Identity | |
| Weaknesses | CWE-639 | |
| References |
|
|
| Metrics |
cvssV3_1
|
Projects
Sign in to view the affected projects.
Status: PUBLISHED
Assigner: VulnCheck
Published:
Updated: 2026-08-21T11:22:51.779Z
Reserved: 2026-08-21T11:09:25.553Z
Link: CVE-2026-77776
No data.
Status : Received
Published: 2026-08-21T12:16:36.967
Modified: 2026-08-21T12:16:36.967
Link: CVE-2026-77776
No data.
OpenCVE Enrichment
Updated: 2026-08-21T12:45:04Z
Weaknesses