Description

Headroom compresses data before the data reaches a large language model. Prior to version 0.35.0, the Headroom WebSocket server does not validate the `Origin` header of incoming client WebSocket requests before forwarding the request to the upstream server, allowing malicious WebSocket clients to perform arbitrary LLM requests without authentication. This can be exploited by a malicious WebSocket client executed in a traditional or headless browser such as lightpanda, if the browser has access to the Headroom proxy and the OpenAI API key is stored in the `OPENAI_API_KEY` environment variable. Version 0.35.0 fixes the issue.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-09-11T14:17:32.390Z",
  "pubdate": "2026-09-11T14:17:32.390Z",
  "executiveSummary": "Headroom versions prior to 0.35.0 are vulnerable to an unauthorized WebSocket request forwarding flaw caused by missing Origin header validation.\nThe vulnerability allows an unauthenticated, malicious WebSocket client to hijack the proxy server to execute arbitrary requests against upstream Large Language Model (LLM) endpoints.\nBy bypassing origin checks, an attacker can leverage the server's environment-stored credentials, specifically the OpenAI API key, to perform unauthorized operations.\nExploitation requires the attacker to be capable of executing a WebSocket client, such as a traditional or headless browser like lightpanda, that maintains network reachability to the Headroom proxy.\nThis represents a significant security risk, as it enables unauthorized usage of API quotas and potential data exfiltration or manipulation through the LLM interface without verifying the legitimacy of the request origin.\nSuccessful exploitation depends on the existence of the OPENAI_API_KEY environment variable within the proxy server's execution context.",
  "technicalDetails": "The root cause of this vulnerability lies in the improper implementation of WebSocket handshake security within the Headroom proxy server. Specifically, the component responsible for processing incoming WebSocket connection requests fails to inspect and validate the 'Origin' header.\nIn standard browser-based environments, the 'Origin' header is automatically included by the User-Agent during the WebSocket opening handshake to identify the source of the connection. By neglecting to enforce strict validation against this header, the Headroom server cannot distinguish between authorized requests originating from trusted clients and malicious requests initiated by unauthorized actors.\nThe attack flow proceeds as follows: 1) A malicious actor deploys a WebSocket client (e.g., via a headless browser environment like lightpanda) with access to the network segment where the Headroom proxy resides. 2) The malicious client initiates a WebSocket connection to the Headroom proxy server. 3) Because the proxy lacks Origin verification, the server establishes the WebSocket tunnel without validating the caller's identity or origin. 4) The attacker subsequently sends LLM-specific request payloads through the established WebSocket tunnel. 5) The Headroom proxy, acting as an intermediary, transparently forwards these requests to the upstream LLM provider, utilizing the cached OPENAI_API_KEY environment variable. 6) The LLM provider processes the request, treating it as a legitimate operation initiated by the proxy owner, thereby facilitating unauthorized access or consumption of resources.\nThis vulnerability is present in all Headroom versions prior to 0.35.0. The lack of authentication and authorization controls at the proxy layer means that any entity with network path connectivity to the WebSocket server can interact with the upstream LLM API. The post-exploitation impact includes the misuse of API keys, unauthorized inference execution, potential data manipulation depending on the LLM's capabilities, and the concealment of the true source of the request, as all traffic appears to originate from the Headroom proxy host. The failure to perform these checks renders the proxy an open relay for LLM traffic, effectively granting anonymous third parties the same privileges as the proxy server itself."
}