Log in Start free

Vulnerability · Published Aug 21, 2026 · Assigned by VulnCheck

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

Critical 9.1

In plain English

A critical-severity authorization bypass via user-controlled key in Headroom from Headroom Labs. There are no confirmed reports of exploitation so far. The chance it is exploited in the next 30 days is estimated at 0.6% (higher than 50% of all known vulnerabilities).

Severity (CVSS 3.1)9.1Critical
Exploit odds (30 days)0.6%top 50.5% of all CVEs
Exploited in the wildNo reportsCISA SSVC: none
Attack toolingNoneno public tooling known

Official 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 (as reported)

VendorProductVersions
Headroom Labs Headroom 0 – before 0.36.1

Weakness: CWE-639 · Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

References