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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.1",
  "pubDate": "2026-08-21T12:16:36.967Z",
  "pubdate": "2026-08-21T12:16:36.967Z",
  "executiveSummary": "Headroom's LLM proxy suffers from an insecure memory ownership derivation vulnerability involving the handling of request headers. The vulnerability resides in the proxy component where memory ownership is directly assigned from the unvalidated x-headroom-user-id request header without cryptographically binding the value to the authenticated caller.\nThis flaw allows malicious network-adjacent or remote actors to arbitrarily read or write stored LLM memory belonging to other users by spoofing the user identifier in the header.\nThe risk is significantly amplified under default or reference deployment configurations, specifically the reference docker-compose.yml file which ships with --host 0.0.0.0 binding and published ports, combined with the absence of a required HEADROOM_PROXY_TOKEN. Consequently, deployments utilizing this reference configuration expose the affected data-plane routes to the network without requiring authentication, permitting unauthenticated attackers to conduct cross-user data access and manipulation across chat completion and websocket paths.\nMitigation requires implementing proper identity resolution seams, enforcing strict validation of caller trust, requiring proxy tokens, and avoiding insecure network bindings on public interfaces.",
  "technicalDetails": "The root cause of the vulnerability stems from the direct ingestion of the x-headroom-user-id request header at multiple execution points within headroom/proxy/handlers/openai.py, encompassing both chat completion and websocket paths. The application logic trusts the user identifier provided in this header outright, failing to establish a secure cryptographic or session-based binding between the caller and the declared memory owner.\nExploitation occurs when an external client sends crafted HTTP or websocket requests to the LLM proxy containing an arbitrary, guessed, or enumerated user identifier within the x-headroom-user-id header. Because the application lacks validation or a secure seam such as the introduced resolve_memory_identity in headroom/proxy/identity.py, the proxy processes the request under the context of the supplied victim identifier. This grants the attacker the ability to inspect historical context, sensitive conversational data, or inject malicious payloads into another user's stored LLM memory.\nThe attack flow is facilitated by the default network exposure defined in the reference docker-compose.yml, which binds the service to 0.0.0.0 and publishes ports externally. In conjunction with an unset or default HEADROOM_PROXY_TOKEN—despite server startup warnings—the data-plane routes are fully exposed to untrusted network traffic without authentication. Attackers do not require prior privileges or valid credentials against the service; network access to the exposed proxy port is sufficient to initiate exploitation.\nPost-exploitation impact includes complete confidentiality and integrity compromise of user-specific LLM memory stores. Attackers can exfiltrate sensitive data processed by the LLM or poison the memory context of arbitrary users interacting with the proxy."
}