CVE-2026-77776: Headroom Proxy Treats the Client-Supplied x-headroom-user-id Header as an Authenticated Identity

Severity: critical (CVSS 9.1 v3.1)
Exploited in the wild: not listed in CISA KEV
EPSS: 0.6% probability of exploitation in the next 30 days
Public exploit or detection template: none known
Published: 2026-08-21 · updated 2026-10-15
Weakness: CWE-639

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.

Affected products

Headroom Labs Headroom: before 0.36.1 — fixed in 0.36.1

How to fix

Upgrade to a fixed version: Headroom Labs Headroom 0.36.1. Check the vendor advisory for mitigations.

References

Get alerted when CVE-2026-77776 or the next vulnerability affects your stack