Headroom EUVD-2026-76105

Three conditions must be met simultaneously: (1) the Headroom WebSocket proxy is reachable from the victim's browser-either because it is bound to localhost in a developer's environment, hosted on an intranet, or (worst case) exposed to the internet; (2) the OPENAI_API_KEY environment variable is configured in the Headroom process; and (3) the victim loads a malicious or compromised webpage in a browser that has network access to the proxy endpoint, or a headless browser such as lightpanda is used in an automated pipeline. User interaction is required in the traditional browser case (UI:R), but headless-browser pipelines that automatically load external content could reduce this barrier. Exploitation is bounded by network topology: deployments accessible only on localhost or a hardened private network cannot be reached by external attackers without additional compromise.

The CVSS 8.8 vector (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) accurately reflects the attack profile: network-reachable, low complexity, no attacker credentials required, but gated on the victim's browser having network access to the proxy endpoint. No EPSS score is provided in the input data, and KEV status is absent-no active exploitation confirmed by any authoritative source. The realistic blast radius is constrained by deployment topology: Headroom is typically a developer or team-internal tool, meaning exploitation requires either an insider threat, a malicious script on an intranet page, or a phishing lure that reaches a developer whose browser touches the proxy. Even a mid-sized engineering organization in bytom running Headroom behind a VPN faces meaningful but not critical external exposure, since internet-routed attackers cannot reach a LAN-only proxy directly. The most concrete risk is API key exhaustion and financial damage to the OpenAI account; secondary risk is prompt injection enabling data exfiltration through LLM response channels. CVSS C:H/I:H/A:H is defensible but slightly generous given S:U scope.

An attacker crafts a webpage containing JavaScript that opens a WebSocket connection to the target's Headroom proxy address (e.g., ws://headroom.internal:4000). When a developer whose browser has intranet access to the proxy visits the page, the browser completes the WebSocket handshake without any Origin check by the server. The attacker's script then streams arbitrary LLM requests through the proxy, billing the operator's OpenAI account and potentially extracting LLM-generated responses containing sensitive organizational context.