Headroom AI proxy accepts WebSocket requests from any web page

A security advisory published on GitHub on 2 October 2026 says the Headroom proxy server can be hijacked by any web page a user visits, letting an attacker send arbitrary requests to OpenAI using the proxy operator's API key.

The flaw is tracked as CVE-2026-71416 and the advisory identifier GHSA-h46j-26q3-rggf. It affects the Python package headroom-ai, which runs a local proxy for large language model traffic. According to the advisory, the problem is that Headroom's WebSocket server does not validate the Origin header of incoming client connections before forwarding them upstream. The Origin header tells a server which web page opened the connection, and checking it is the standard defence against cross-site WebSocket hijacking.

The advisory points to a WebSocket handler at ws://<headroom_host>:8787/v1/responses, defined in headroom/providers/proxy_routes.py and implemented in the handle_openai_responses_ws method of the OpenAIHandlerMixin class. The code calls websocket.accept() without inspecting the Origin header, which the advisory says "grants any WebSocket client (including malicious clients) access to the server".

Two design choices combine to make the issue worse. The advisory notes that a malicious client does not need to supply an API key of its own, because Headroom falls back to the OPENAI_API_KEY environment variable when no Authorization header arrives with the connection. The code comment in the advisory describes this as a "safety net for clients that don't forward auth headers via WebSocket upgrade". The result, according to the advisory, is that an unauthenticated client can issue arbitrary LLM requests, including its own instructions, input prompts and tool definitions, billed to the proxy owner's account.

The advisory includes a proof of concept. The researcher started the proxy with OPENAI_API_KEY set and the --host 0.0.0.0 flag, then loaded a short HTML page containing JavaScript that opened a WebSocket to the proxy on port 8787 and sent a response.create message. The payload specified the model gpt-5.4, an instruction describing a local Linux shell, the input "Run the id command for the logged in user", and a shell tool with a local environment. The advisory says the page works in an ordinary browser or a headless browser such as lightpanda, provided the browser can reach the Headroom proxy.

In the logged output, the proxy accepted the connection and forwarded the request: the server returned response.created and response.in_progress events from the OpenAI Responses API. The researcher said the account used had insufficient quota to complete the request, but that the exchange "proves that it was attempted". The advisory adds that the shell tool was used only as a demonstration and that any tool, input or instruction prompt could be substituted.

The advisory does not list a fixed version, a patch or a workaround, and does not say whether the flaw has been exploited outside the researcher's test. It describes the exposure as requiring network access to the Headroom proxy, which in the proof of concept was achieved simply by getting a browser on the same network to render a web page.

Operators running headroom-ai should note that the proof of concept binds the proxy to all interfaces, which widens the set of machines that can reach port 8787.