Headroom CVE-2026-77776

The affected data-plane routes must be network-reachable, which is the case for deployments following the shipped docker-compose.yml (--host 0.0.0.0, published ports, and no HEADROOM_PROXY_TOKEN set). Under those conditions exploitation is remote and unauthenticated (CVSS PR:N/UI:N): the attacker only needs to send the x-headroom-user-id header naming a target user against the chat-completion or websocket path and know or guess a victim's identifier. Limiting factors: the pip console script binds 127.0.0.1 by default, so a loopback-only install is not remotely exploitable; deployments that set a proxy token or restrict the bind/published port to loopback are protected; and the attacker must reach the exposed port and reference a valid user identifier.

This is a genuine high-priority issue for network-exposed deployments, not merely a high-CVSS paper cut. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H) rates it 9.3, and the mechanism supports that: forging one header value yields both read and write access to another user's memory with no authentication and no user interaction. The critical caveat is deployment-dependent - the pip console script binds 127.0.0.1 and is not remotely reachable, so the network-unauthenticated rating applies specifically to installs following the reference docker-compose.yml, which ships --host 0.0.0.0 with published ports and no mandatory proxy token (a state the server itself warns about at startup). EPSS is not provided and this is not on CISA KEV, so widespread automated exploitation is not evidenced; the realistic risk is targeted abuse against any operator who deployed the stock compose file on a reachable network. Any team running the Docker reference deployment should treat patching to 0.36.1 as urgent, since memory poisoning can also feed manipulated context back into downstream LLM interactions.

An attacker who can reach a Headroom proxy deployed via the stock docker-compose (0.0.0.0, no token) sends a chat-completion or websocket request with x-headroom-user-id set to a victim's identifier. The proxy treats that header as the authenticated owner, returning the victim's stored LLM memory and accepting writes to it. No exploit code is published, but the attack is trivial to reproduce from the description and PR diff, requiring only a crafted HTTP header.