CVE-2026-107685: WebSocket sessions do not verify TLS certificates, exposing API keys and OAuth tokens to on-path attackers
- Is it exploited?
Not on CISA's list. CISA has not added it to the Known Exploited Vulnerabilities catalog as of . If CISA adds it, this page shows it as known exploited.
- How likely is exploitation in the next 30 days?
- 0.3%
EPSS score, percentile 20 of all scored records. A probability estimated by FIRST, not a report of exploitation.
CISA's SSVC assessment in the CVE record lists exploitation as poc.
- How severe?
- 9.1 Critical
CVSS v4.0 base score, given by the CNA
- What should I do?
CISA has set no required action, because the vulnerability is not in KEV.
- Which versions are affected?
Affected
- from 1.9.0 to before 1.29.0
Source: CISA KEV 2026.11.10, as of ; FIRST EPSS, as of ; CVE List, as of . About the data.
Description
WebSocket sessions do not verify TLS certificates, exposing API keys and OAuth tokens to on-path attackers
Improper Certificate Validation vulnerability in the WebSocket streaming client in agentjido req_llm allows an on-path attacker to read and modify OpenAI WebSocket sessions, including the authorization bearer token, via a TLS certificate the client does not trust. ReqLLM.Streaming.WebSocketSession.Client.start/3 in lib/req_llm/streaming/web_socket_session/client.ex starts WebSockex without TLS options, and WebSockex defaults to insecure: true, which connects with verify: :verify_none. The option allowlist also drops any caller-supplied cacerts or ssl_options, so an application cannot turn verification on. The OpenAI Responses, Realtime, and Codex WebSocket paths reach this client and send the API key or OAuth access token in the authorization header. HTTP streaming through Finch and the HTTP/2 duplex session through Mint verify certificates and are not affected. This issue affects req_llm: from 1.9.0 before 1.29.0.
Source: CVE List, as of . About the data.
What to do
Advisories and patches
- Fix commit c7264fc in agentjido/req_llm
- WebSocket sessions do not verify TLS certificates, exposing API keys and OAuth tokens to on-path attackers
Workaround (from the CVE record)
Leave the openai_stream_transport provider option at its default :sse for the OpenAI and OpenAI Codex providers, and do not call ReqLLM.Providers.OpenAI.WebSocket.start_responses_session/2 directly. Responses streaming then runs over HTTP through Finch, which verifies certificates. ReqLLM.OpenAI.Realtime.connect/2 has no HTTP alternative, so do not use it on an affected version.
This summary is based on the CVE record as of . Check the vendor's advisory before you act: affected versions and fixes can change.
Affected products and versions
Versions by product, as listed in the CVE record (2 products)
| Status | Versions |
|---|---|
| Affected | from 1.9.0 to before 1.29.0 |
Versions not listed are: unaffected.
| Status | Versions |
|---|---|
| Affected | from a389d718640c to before c7264fc0217f |
Versions not listed are: unaffected.
Source: CVE List, as of . About the data.
Weakness
CWE-295, 1 CAPEC
- CWE-295: Improper Certificate Validation
Attack patterns (CAPEC)
- CAPEC-94: An attacker on the network path between an application and the OpenAI endpoint presents their own certificate, obtains the OpenAI API key or OAuth access token…
CWE and CAPEC are maintained by MITRE; the entries are those named in the CVE record.
Timeline
| Date | Event |
|---|---|
| CVE record published | |
| CVE record last updated |