External risk intelligence

Headroom LLM Proxy User ID Spoofing Leads to Memory Access

CVE advisorySeverity: CRITICAL (CVSS 9.3)

CVE-2026-77776

The application is an LLM proxy service. The provided reference docker-compose configuration defaults to binding the service to all network interfaces (0.0.0.0) with published ports and no authentication required by default, making it highly likely to be exposed as an internet-facing service or internal gateway in common real-world containerized deployments.

Halo Surface Signal: 4 out of 5 — likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

This advisory concerns a vulnerability in an LLM proxy technology where a client could impersonate another user's identity. This allows unauthorized access to read or write another user's stored language model memory, posing a risk to data privacy and integrity. The primary concern is confirming if this specific technology is in use and exposed without proper authentication.

Unauthorized access to user memory is possible.
Protects sensitive LLM memory from misuse.
Confirm technology use and exposure status.

Attack Path

How an attacker could exploit the issue

An attacker can impersonate another user by sending a malicious request with a fabricated `x-headroom-user-id` header. This allows them to access or modify that user's stored LLM memory. The default configuration of the application, when deployed using the provided Docker Compose file, exposes this vulnerability to the network without requiring any authentication.

Unauthenticated network access.
Malicious user ID header.
Unauthorized memory access or modification.

Live Threat

Current exploitation, exposure, and threat context

When the proxy is deployed without authentication, an attacker could impersonate any user by manipulating the `x-headroom-user-id` header. This could allow them to read or write another user's stored LLM memory.

User LLM memory data.
Via unauthenticated network requests.
Unauthorized memory access.

Operational Fix

Recommended remediation, mitigation, and detection steps

Responsible teams include platform or infrastructure owners managing the LLM proxy, and security teams overseeing network access and authentication. The first practical step is to identify all instances of the LLM proxy, determine their network exposure and business criticality, and then locate the accountable owner for each instance to plan remediation.

Platform or Security teams should own this issue.
Verify network exposure and authentication status.
Plan remediation with accountable owners.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is the Headroom LLM proxy?

Headroom is a software tool that acts as an intermediary for language model interactions. It manages user sessions and stores historical memory, allowing applications to maintain context across multiple interactions. By sitting between clients and the model, it handles request routing and identity tracking.

How does CVE-2026-77776 enable identity spoofing?

This vulnerability involves a weakness in authorization, categorized as CWE-639 (Authorization Bypass Through User-Controlled Key). The proxy trustfully accepts a user identifier from a client-provided request header without verifying the caller's legitimacy. Consequently, an attacker can manipulate this header to masquerade as any other user, gaining full control over their stored memory.

Do I need to authenticate to trigger this flaw?

No. The vulnerability does not require authentication because the software fails to bind the request to a valid identity. It is triggered simply by crafting a request with a target user's ID. Note that this bug is not triggered if the service is configured to require a valid proxy token or is strictly limited to local, loopback-only connections as intended in more secure deployment setups.

Is my deployment at risk according to Halo Surface Signal?

Halo Surface Signal indicates a high likelihood of risk if you use the reference docker-compose configuration. This default setup binds the proxy to all network interfaces and publishes ports without enforcing a proxy token. This common configuration often leaves the service accessible to the broader network rather than restricting it to internal-only communication.

What is the first step to remediate this issue?

Your priority is to audit your environment to locate all running instances of the Headroom proxy. Once identified, evaluate how each instance is networked and verify if it is currently operating without authentication. Following this discovery phase, coordinate with the infrastructure owners to ensure that required authentication tokens are enabled or that network access is properly restricted.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.