CVE-2026-71416: Headroom WebSocket Auth Bypass Vulnerability

CVE-2026-71416 Overview

Headroom is a proxy that compresses data before forwarding it to a large language model (LLM). Versions prior to 0.35.0 contain an authentication weakness [CWE-287] in the WebSocket server. The server forwards incoming client WebSocket requests to the upstream LLM provider without validating the Origin header. A malicious WebSocket client running in a traditional or headless browser can perform arbitrary LLM requests using the operator's credentials. Exploitation succeeds when the browser reaches the Headroom proxy and the OPENAI_API_KEY environment variable is set. Version 0.35.0 addresses the flaw.

Critical Impact
Unauthenticated attackers can issue arbitrary LLM requests through a victim's Headroom proxy, consuming their OpenAI API quota and exfiltrating model responses.

Affected Products

Headroom (headroomlabs-ai/headroom) versions prior to 0.35.0
Deployments exposing the Headroom WebSocket proxy to browser-reachable networks
Environments where OPENAI_API_KEY is provisioned to the Headroom process

Discovery Timeline

2026-09-11 - CVE-2026-71416 published to the National Vulnerability Database
2026-09-11 - Last updated in NVD database

Technical Details for CVE-2026-71416

Vulnerability Analysis

Headroom acts as a compression proxy between clients and upstream LLM APIs such as OpenAI. Clients connect via WebSocket, and the server forwards requests upstream using the operator-configured API key held in the OPENAI_API_KEY environment variable. The vulnerable server accepts WebSocket handshakes without inspecting the Origin header. Browsers do not enforce the Same-Origin Policy for WebSocket connections, so any web page a victim visits can initiate a cross-origin WebSocket to ws:// endpoints reachable from the browser. The proxy treats these attacker-originated connections as legitimate and forwards prompts upstream using the operator's API key.

Root Cause

The root cause is missing authentication of the request source [CWE-287]. The WebSocket handshake handler in versions prior to 0.35.0 does not compare the client-supplied Origin header against an allowlist and does not require any other authentication token. Without origin checking or a shared secret, the server cannot distinguish a first-party client from a cross-site WebSocket hijack attempt.

Attack Vector

An attacker hosts a page containing JavaScript that opens a WebSocket to the victim's Headroom proxy address. When the victim visits the page in a traditional browser, or when a headless browser such as lightpanda is directed at the malicious page while sharing network access to the proxy, the WebSocket connection is accepted. The attacker then streams arbitrary prompts through the proxy. Headroom forwards each request to OpenAI using the operator's OPENAI_API_KEY, returning model output to the attacker. This yields quota abuse, financial cost, and potential exposure of upstream conversation content. The vulnerability manifests entirely at the handshake layer. See the GitHub Security Advisory GHSA-h46j-26q3-rggf for further technical detail.

Detection Methods for CVE-2026-71416

Indicators of Compromise

Unexpected spikes in OpenAI API usage or billing tied to the Headroom service account
WebSocket handshake requests to the Headroom port carrying an Origin header that does not match a known internal application
Upstream LLM prompts or completions in Headroom logs that do not correlate with any authenticated user session
Outbound requests from headless browser user agents such as lightpanda reaching the Headroom proxy

Detection Strategies

Inspect reverse-proxy or Headroom access logs for WebSocket Upgrade requests where the Origin header is absent, external, or unrecognized
Correlate OpenAI billing telemetry against internal application usage to surface unattributed request volume
Alert on Headroom process network egress spikes that are not preceded by first-party client activity

Monitoring Recommendations

Forward Headroom and reverse-proxy access logs to a centralized logging platform and retain the Origin, User-Agent, and source IP fields
Set thresholds on OpenAI API cost and token counts per hour to catch abuse windows early
Monitor for connections to the Headroom listener from source addresses outside the intended client subnet

How to Mitigate CVE-2026-71416

Immediate Actions Required

Upgrade Headroom to version 0.35.0 or later, which validates the WebSocket Origin header
Rotate the OPENAI_API_KEY if the proxy was reachable from untrusted browsers prior to upgrade
Restrict network exposure of the Headroom listener to trusted client subnets or loopback

Patch Information

The maintainers fixed the issue in Headroom 0.35.0 by validating the Origin header on incoming WebSocket connections before forwarding requests upstream. Release notes are available in the GitHub Release v0.35.0 and the GitHub Security Advisory GHSA-h46j-26q3-rggf.

Workarounds

Bind the Headroom WebSocket listener to 127.0.0.1 and require access through an authenticated reverse proxy
Enforce an Origin header allowlist at an upstream reverse proxy such as nginx or Caddy
Remove OPENAI_API_KEY from the Headroom process environment when the service is not actively required
Place the Headroom proxy behind mutual TLS or a network-level authentication gateway

bash

# nginx example: reject WebSocket upgrades with unexpected Origin headers
map $http_origin $origin_allowed {
    default              0;
    "https://app.internal.example"  1;
}

server {
    listen 8443 ssl;
    location /headroom/ {
        if ($origin_allowed = 0) { return 403; }
        proxy_pass http://127.0.0.1:8080;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}