Security readout for executives and security teams
Plain-English summary
Headroom’s LLM proxy trusted a user-controlled header as proof of identity. An unauthenticated network client could claim another user’s identifier and access or alter that user’s stored LLM memory. Confidentiality and integrity risks are severe, particularly where the proxy follows the shipped Docker Compose configuration and is reachable beyond the host.
Executive priority
Immediate action is warranted for network-accessible deployments because unauthorized clients may read or modify sensitive conversational memory without credentials. Restrict exposure and require authentication now, then apply the vendor-supported correction. Also investigate possible cross-user access where the proxy was previously exposed without a token.
Technical view
CVE-2026-77776 is a CWE-639 authorization flaw. Chat-completion and WebSocket handlers derive memory ownership directly from x-headroom-user-id without binding it to the caller. The documented fix centralizes identity resolution, accepting that header only from loopback or allowlisted callers and otherwise using a proxy-token fingerprint or operating-system user.
Likely exposure
Highest exposure exists where Headroom’s proxy listens on 0.0.0.0, publishes ports, and does not require HEADROOM_PROXY_TOKEN, as described for the reference Docker Compose deployment. The bundle lists Headroom versions 0 and 0.36.1 as affected; the exact vulnerable version range is unclear.
Exploitation context
The weakness is remotely reachable, low complexity, requires no privileges or user interaction, and can compromise stored memory confidentiality and integrity. The supplied record is not in KEV, and the cited material does not establish active exploitation. Treat internet-accessible or broadly network-accessible deployments as urgent despite the absence of confirmed exploitation.
Researcher notes
The core invariant is that memory ownership must derive from authenticated caller context, not a client assertion. Review both HTTP chat-completion and WebSocket paths. The source bundle identifies a centralized resolve_memory_identity seam, but does not clearly identify the first fully fixed release or provide evidence of exploitation in the wild.
Mitigation direction
- Follow vendor guidance and Pull Request #2207 for the corrected identity-resolution implementation.
- Require HEADROOM_PROXY_TOKEN for every non-loopback deployment.
- Bind the proxy to loopback unless remote access is operationally necessary.
- Restrict published proxy ports to explicitly trusted callers using network controls.
- Avoid trusting x-headroom-user-id from unallowlisted network clients.
Validation and detection
- Inventory deployed headroom-ai versions and compare them with current vendor guidance.
- Confirm proxy listeners are not unintentionally bound to 0.0.0.0.
- Verify non-loopback requests require a valid proxy token.
- Review Docker Compose and runtime arguments for published, unauthenticated proxy ports.
- Confirm identity resolution binds remote callers to token fingerprints rather than supplied headers.
- Review access logs for unexpected user identifiers or cross-user memory activity.
Public sources used
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
CWE-639: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
Open ATT&CK lookupCredential and access behavior lookup
The CVE wording references authentication or credential exposure, so valid-account and credential-access review may help. This is a Glexia inferred lookup path, not an official MITRE, ATT&CK, or CVE Program mapping.
Open ATT&CK lookupContainer behavior lookup
The affected technology mentions containers, so container-specific ATT&CK technique review may help. This is a Glexia inferred lookup path, not an official MITRE, ATT&CK, or CVE Program mapping.
Open ATT&CK lookupCVE-2026-77776 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
Open ATT&CK lookup- Severity
- Critical
- CVSS
- 9.3 (4.0)
- Known Exploited
- No
- Published
Vector: 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
CNA and ADP enrichment extracted from CVE v5
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
SSVC decision data
CVSS vector scores
2 official scoresWe collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
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——VulnCheckCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N3.95.2VulnCheckVulnerability scoring details
Base CVSS 4.0 score
9.3CriticalVector: 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
Base CVSS 3.1 score
9.1CriticalVector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
- CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
- CVE publishedCVE Program
The CVE record was published.
- CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.
ADP provider summaries
Source materials
- CVE List V5 sourceCVE List V5
- Pull Request #2207 addressing the assessment findingsCVE reference, VulnCheck · issue-tracking
- Header handling in the OpenAI proxy handler at v0.29.0CVE reference, VulnCheck · technical-description
- resolve_memory_identity seam introduced by the fixCVE reference, VulnCheck · technical-description
- https://github.com/headroomlabs-ai/headroomCVE reference, VulnCheck · product
- VulnCheck Advisory: Headroom Proxy Treats the Client-Supplied x-headroom-user-id Header as an Authenticated IdentityCVE reference, VulnCheck · third-party-advisory
Products and packages named in the record
CWE details
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
Authorization Bypass Through User-Controlled Key
Authorization Bypass Through User-Controlled Key represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.