EUVD-2026-63905
GHSA-5vg3-c628-vf56
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessReach exposed 0.0.0.0 proxy port
-
DeliverySend request with forged x-headroom-user-id header
-
ExploitProxy trusts header as owner identity
-
ExecutionRead or overwrite victim's stored LLM memory
-
ImpactExfiltrate secrets or poison future model context
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Object-level authorization, IDOR prevention
|
| Exploitation Conditions | 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. |
| Impact | 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. |
| Exploit ScenarioDerived | 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. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv2 – Aug 21, 2026
Cross-user memory disclosure and tampering in Headroom's LLM proxy (versions before 0.36.1) lets a caller read or overwrite any user's stored LLM memory by simply naming another user's identifier in the client-supplied x-headroom-user-id request header. The proxy trusts this header as the authenticated identity across the chat-completion and websocket data-plane paths in headroom/proxy/handlers/openai.py, with nothing binding the value to the actual caller. The console script binds loopback by default, but the shipped docker-compose.yml publishes the proxy on 0.0.0.0 with no required proxy token, so a stock Docker deployment exposes these routes to the network unauthenticated. Reported by VulnCheck; no public exploit identified at time of analysis.
Earlier versions of this analysis (1)
Cross-user memory access in Headroom's LLM proxy (through v0.29.0-era builds, fixed in v0.36.1) lets a caller impersonate any user by setting the x-headroom-user-id request header, which the proxy trusts as an authenticated identity without binding it to the caller. Any client that can reach the chat-completion or websocket routes can read or overwrite another user's stored LLM memory. Reported by VulnCheck; no public exploit identified at time of analysis and the flaw is not listed in CISA KEV.
RemediationAI
Vendor-released patch: upgrade to Headroom 0.36.1 or later (PR #2207), which adds resolve_memory_identity so the x-headroom-user-id header is honored only for loopback or allowlisted callers and identity is otherwise bound to the proxy-token fingerprint or OS user. If you cannot upgrade immediately, do not expose the proxy on the network: keep the bind on 127.0.0.1 (the pip console-script default) rather than 0.0.0.0, and if you use the reference docker-compose, set a strong HEADROOM_PROXY_TOKEN (openssl rand -hex 32) and confine the published port to host loopback so the data plane is never open without a token - note the trade-off that this removes remote/multi-host access. Additionally set NEO4J_AUTH to non-default credentials and keep the Neo4j Bolt port loopback-only, and leave Neo4j APOC file import/export disabled, since the same advisory/PR flags the shipped default Neo4j password and APOC settings as an exposed-database risk. Advisory and patch: https://github.com/headroomlabs-ai/headroom/pull/2207 and https://www.vulncheck.com/advisories/headroom-proxy-treats-the-client-supplied-x-headroom-user-id-header-as-an-authenticated-identity.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Headroom is an LLM proxy/memory layer (CPE cpe:2.3:a:headroom_labs:headroom) that stores per-user memory a model can read and write. The vulnerability is a classic CWE-639 (Authorization Bypass Through User-Controlled Key / IDOR): the memory owner is derived from an attacker-controllable request header rather than from an authenticated session or credential. Because the identifier IS the authorization key and is caller-supplied, any value the client sends is honored. The fix (PR #2207) centralizes identity resolution in a new headroom/proxy/identity.py resolve_memory_identity seam that only honors the header for loopback or explicitly allowlisted callers, and otherwise binds identity to the proxy-token fingerprint or the OS user. The same PR hardens the deployment surface: docker-compose now requires HEADROOM_PROXY_TOKEN and NEO4J_AUTH (removing published default credentials), keeps the Neo4j Bolt port loopback-only, and leaves APOC file import/export disabled.
Know when Headroom gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
Network-reachable exposed compose deployment needs no auth or interaction (AV:N/AC:L/PR:N/UI:N); forged header grants read and write to another user's memory (C:H/I:H), no availability impact.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
Lifecycle Timeline
3DescriptionCVE.org
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.
Articles & Coverage 1
Executive ViewAI
Headroom LLM proxy versions before 0.36.1 contain a critical authentication bypass that allows any network user to read and modify other users' stored LLM conversation data without requiring credentials. The standard Docker deployment configuration exposes the vulnerable proxy to the network unauthenticated, putting all user data at immediate risk of cross-user breaches.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Cross-origin WebSocket hijacking in Headroom's proxy layer (prior to v0.35.0) allows an unauthenticated attacker-control
Server-side request forgery in Headroom LLM proxy (versions before 0.36.1) allows unauthenticated remote attackers to re
Exploit-DB