CVE-2026-71416: CSWSH bypass — HIGH

CISO Take

Headroom is a WebSocket proxy that compresses payloads before they reach an LLM, and prior to version 0.35.0 it forwards any incoming WebSocket connection to the upstream LLM API without validating the request's Origin header. Because the proxy typically holds the organization's OPENAI_API_KEY in its own process environment, any web page or script running in a victim's browser (or a headless browser like lightpanda) that can reach the proxy's listening port can open a cross-origin WebSocket and issue arbitrary LLM requests as if it were an authorized client, with no credentials of its own. There is no CISA KEV listing, no EPSS score, and no public exploit or Nuclei template yet, so exploitation likelihood signals are thin, but the CVSS 8.8 (AV:N/AC:L/PR:N) reflects that the only real barrier is getting a browser with network access to the proxy to load attacker-controlled content — a low bar in local dev setups or internal tooling exposed on a browser-reachable port. Upgrade to Headroom 0.35.0 or later immediately; until patched, restrict network access to the WebSocket proxy to trusted hosts and audit upstream LLM API usage/billing logs for anomalous request volume or unexpected origins as a compromise indicator.

Sources: NVD GitHub Advisory ATLAS

What is the risk?

High severity (CVSS 8.8) driven by network attack vector, low complexity, and no privileges required — the only mitigating factor is the required user interaction (a victim's browser must load attacker content). Exploitation likelihood signals (EPSS, KEV, public exploit, scanner templates) are all absent, and downstream dependent counts are unknown, so real-world exploitation pressure cannot be confirmed at this time. However, the flaw is trivial to exploit once a victim's browser has network reach to the proxy, since it requires no authentication bypass technique beyond issuing a WebSocket handshake from an arbitrary origin (classic CSWSH pattern). Organizations running Headroom on developer machines, internal networks, or anywhere reachable from a browser should treat this as high risk pending confirmation of external exposure.

How does the attack unfold?

Initial Access

Attacker gets a victim to load attacker-controlled content in a browser (or headless browser) that has network access to the Headroom WebSocket proxy.

AML.T0078

Exploitation

Malicious page JavaScript opens a cross-origin WebSocket connection to the Headroom proxy, which forwards it upstream without validating the Origin header.

AML.T0049

Unauthorized API Access

The attacker issues arbitrary LLM requests through the proxy using the victim's stored OPENAI_API_KEY, with no credentials of their own.

AML.T0040

Impact

The victim's LLM account incurs unauthorized usage costs and potential data exposure from attacker-controlled prompts and responses.

AML.T0034

Initial Access

Attacker gets a victim to load attacker-controlled content in a browser (or headless browser) that has network access to the Headroom WebSocket proxy.

AML.T0078

Exploitation

Malicious page JavaScript opens a cross-origin WebSocket connection to the Headroom proxy, which forwards it upstream without validating the Origin header.

AML.T0049

Unauthorized API Access

The attacker issues arbitrary LLM requests through the proxy using the victim's stored OPENAI_API_KEY, with no credentials of their own.

AML.T0040

Impact

The victim's LLM account incurs unauthorized usage costs and potential data exposure from attacker-controlled prompts and responses.

AML.T0034

How severe is it?

CVSS 3.1

8.8 / 10

EPSS

0.2%

chance of exploitation in 30 days

Higher than 7% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Trivial

Exploitation Confidence

medium

○ CISA SSVC: Public PoC

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AV Network

AC Low

PR None

UI Required

S Unchanged

C High

I High

A High

What should I do?

1 step

Upgrade Headroom to version 0.35.0 or later, which validates the Origin header before forwarding WebSocket connections upstream. If immediate upgrade isn't possible, restrict network-level access to the Headroom WebSocket port to trusted internal hosts only (firewall rules, localhost-only binding, or VPN-gated access) and avoid exposing it to any host that also runs a general-purpose browser. Rotate the OPENAI_API_KEY if there is any suspicion of prior exposure, and add outbound request monitoring/rate-limiting on the upstream LLM account to catch anomalous usage. For detection, review LLM provider usage logs for request spikes, unexpected request patterns, or activity outside of known application usage windows.

What does CISA's SSVC say?

Decision Attend

Exploitation poc

Automatable No

Technical Impact total

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Auth Bypass Data Leakage API Inference AML.T0034 - Cost Harvesting AML.T0040 - AI Model Inference API Access AML.T0049 - Exploit Public-Facing Application

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.8 - AI system operational security

OWASP LLM Top 10

LLM10:2025 - Unbounded Consumption

Frequently Asked Questions

What is CVE-2026-71416?

Headroom is a WebSocket proxy that compresses payloads before they reach an LLM, and prior to version 0.35.0 it forwards any incoming WebSocket connection to the upstream LLM API without validating the request's Origin header. Because the proxy typically holds the organization's OPENAI_API_KEY in its own process environment, any web page or script running in a victim's browser (or a headless browser like lightpanda) that can reach the proxy's listening port can open a cross-origin WebSocket and issue arbitrary LLM requests as if it were an authorized client, with no credentials of its own. There is no CISA KEV listing, no EPSS score, and no public exploit or Nuclei template yet, so exploitation likelihood signals are thin, but the CVSS 8.8 (AV:N/AC:L/PR:N) reflects that the only real barrier is getting a browser with network access to the proxy to load attacker-controlled content — a low bar in local dev setups or internal tooling exposed on a browser-reachable port. Upgrade to Headroom 0.35.0 or later immediately; until patched, restrict network access to the WebSocket proxy to trusted hosts and audit upstream LLM API usage/billing logs for anomalous request volume or unexpected origins as a compromise indicator.

Is CVE-2026-71416 actively exploited?

No confirmed active exploitation of CVE-2026-71416 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-71416?

Upgrade Headroom to version 0.35.0 or later, which validates the Origin header before forwarding WebSocket connections upstream. If immediate upgrade isn't possible, restrict network-level access to the Headroom WebSocket port to trusted internal hosts only (firewall rules, localhost-only binding, or VPN-gated access) and avoid exposing it to any host that also runs a general-purpose browser. Rotate the OPENAI_API_KEY if there is any suspicion of prior exposure, and add outbound request monitoring/rate-limiting on the upstream LLM account to catch anomalous usage. For detection, review LLM provider usage logs for request spikes, unexpected request patterns, or activity outside of known application usage windows.

What systems are affected by CVE-2026-71416?

This vulnerability affects the following AI/ML architecture patterns: LLM API gateways/proxies, model serving, agent frameworks.

What is the CVSS score for CVE-2026-71416?

CVE-2026-71416 has a CVSS v3.1 base score of 8.8 (HIGH). The EPSS exploitation probability is 0.17%.

What is the AI security impact?

Affected AI Architectures

LLM API gateways/proxiesmodel servingagent frameworks

MITRE ATLAS Techniques

AML.T0034 Cost Harvesting

AML.T0040 AI Model Inference API Access

AML.T0049 Exploit Public-Facing Application

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.8

OWASP LLM Top 10: LLM10:2025

What are the technical details?

Original Advisory

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.

Exploitation Scenario

A developer runs Headroom locally (or on an internal network) to proxy their application's calls to the OpenAI API, with OPENAI_API_KEY set in the proxy's environment. The developer visits a malicious or compromised website in the same browser session, or a headless browser automation task fetches attacker-controlled content. That page's JavaScript opens a WebSocket connection directly to the Headroom proxy's address (e.g., ws://localhost:PORT or an internal IP). Because Headroom does not validate the Origin header, it accepts the connection and forwards the attacker's crafted LLM requests upstream using the victim's API key, allowing the attacker to consume the victim's quota, extract model outputs, or inject arbitrary prompts — all without ever needing valid credentials of their own.

Weaknesses (CWE)

CWE-1385 Missing Origin Validation in WebSockets CWE-1385 Missing Origin Validation in WebSockets CWE-287 Improper Authentication CWE-287 Improper Authentication

CWE-1385 — Missing Origin Validation in WebSockets: The product uses a WebSocket, but it does not properly verify that the source of data or communication is valid.

[Implementation] Enable CORS-like access restrictions by verifying the 'Origin' header during the WebSocket handshake.
[Implementation] Use a randomized CSRF token to verify requests.

Source: MITRE CWE corpus.