)CVE-2026-77776: Headroom LLM Proxy Auth Bypass Vulnerability

CVE-2026-77776 Overview

CVE-2026-77776 affects Headroom's LLM proxy, which derives the memory owner from the client-supplied x-headroom-user-id request header. The header is read directly in headroom/proxy/handlers/openai.py across the chat completion and websocket paths, with nothing binding the value to the caller. A remote client can name another user's identifier and read or write that user's stored LLM memory. The issue is compounded because the reference docker-compose.yml ships with --host 0.0.0.0, published ports, and no required HEADROOM_PROXY_TOKEN, exposing the data-plane routes to the network without authentication.

Critical Impact
Unauthenticated network attackers can impersonate any user identifier and read or overwrite arbitrary users' LLM memory contents through the affected proxy routes.

Affected Products

Headroom LLM Proxy (headroomlabs-ai/headroom) at v0.29.0 and earlier releases containing the vulnerable openai.py handler
Deployments using the reference docker-compose.yml shipped with the project
Fixed in versions incorporating the resolve_memory_identity seam introduced at v0.36.1

Discovery Timeline

2026-08-21 - CVE-2026-77776 published to NVD
2026-08-21 - Last updated in NVD database

Technical Details for CVE-2026-77776

Vulnerability Analysis

The vulnerability is an Authorization Bypass Through User-Controlled Key [CWE-639]. The Headroom LLM proxy treats the x-headroom-user-id HTTP header as an authenticated identity assertion. In headroom/proxy/handlers/openai.py, the header value is used at multiple call sites, including the chat completion and websocket paths, to select the memory owner for read and write operations.

Because the proxy never binds the header value to a verified caller identity, any client can set the header to another user's identifier and operate on that user's stored conversational memory. This exposes stored LLM context, prior prompts, and any secrets a user may have committed to memory.

Root Cause

The proxy conflates a request-supplied hint with an authenticated principal. Identity is read directly from an HTTP header, without a corresponding check that the caller is authorized to act as that principal. The fix introduces a single resolve_memory_identity seam in headroom/proxy/identity.py that honors the header only for loopback callers or explicitly allowlisted sources, and otherwise binds identity to the proxy-token fingerprint or the operating system user.

Attack Vector

Exploitation requires network reachability to the proxy's data-plane routes and no credentials. The pip console script binds 127.0.0.1 by default, which limits exposure to the local host. The reference docker-compose.yml, however, ships --host 0.0.0.0 with published ports and does not require HEADROOM_PROXY_TOKEN. The server itself emits a startup warning about this configuration. A deployment that follows the shipped compose file exposes the affected routes to any client that can reach the container's published port.

An attacker enumerates or guesses target user identifiers, then issues chat completion or websocket requests with x-headroom-user-id set to the target value. Refer to the VulnCheck Security Advisory for further technical detail.

Detection Methods for CVE-2026-77776

Indicators of Compromise

Inbound HTTP requests to Headroom proxy endpoints carrying x-headroom-user-id values that do not match the authenticated session or expected caller.
Proxy startup log entries warning that HEADROOM_PROXY_TOKEN is unset while the listener is bound to 0.0.0.0.
Anomalous memory read or write operations spanning multiple distinct user identifiers from a single source IP within a short window.

Detection Strategies

Inspect proxy access logs for requests where the x-headroom-user-id header originates from non-loopback, non-allowlisted source addresses.
Alert on any Headroom proxy container exposing ports externally without an enforced HEADROOM_PROXY_TOKEN environment variable.
Compare the header-supplied identifier against the connection's proxy-token fingerprint or OS user context and flag mismatches.

Monitoring Recommendations

Forward Headroom proxy logs and container stdout to a centralized logging pipeline to capture identity-related startup warnings.
Monitor egress from the proxy to upstream LLM providers for volume anomalies that correlate with cross-user memory access.
Track network policy for containers running the Headroom image and alert on any exposure of the proxy port to untrusted networks.

How to Mitigate CVE-2026-77776

Immediate Actions Required

Upgrade the Headroom proxy to a version containing the resolve_memory_identity seam introduced at v0.36.1 or later.
Set a strong HEADROOM_PROXY_TOKEN for every deployment and require clients to present it.
Remove --host 0.0.0.0 bindings from docker-compose.yml unless the proxy is protected by an authenticating reverse proxy or private network boundary.
Audit stored LLM memory for evidence of unauthorized reads or writes prior to the patch date.

Patch Information

The fix is implemented in GitHub Pull Request #2207, which centralizes identity resolution in headroom/proxy/identity.py. The resolve_memory_identity function honors the x-headroom-user-id header only for loopback or allowlisted callers and otherwise binds identity to the proxy-token fingerprint or operating system user. Upgrade to v0.36.1 or later from the Headroom repository.

Workarounds

Bind the proxy to 127.0.0.1 and place it behind a reverse proxy that authenticates callers and strips or overwrites the x-headroom-user-id header.
Restrict container network exposure using firewall rules or a Docker network policy so the proxy port is unreachable from untrusted sources.
Require HEADROOM_PROXY_TOKEN in every environment and treat proxy startup warnings about missing tokens as deployment blockers.

bash

# Configuration example
# Remove public port exposure and require a proxy token before upgrading is complete
# docker-compose.yml adjustments
services:
  headroom-proxy:
    command: ["headroom-proxy", "--host", "127.0.0.1"]
    environment:
      HEADROOM_PROXY_TOKEN: "${HEADROOM_PROXY_TOKEN:?token required}"
    ports: []  # do not publish the proxy port to the host network