CVE-2026-107685: WebSocket sessions do not verify TLS certificates, exposing API keys and OAuth tokens to on-path attackers

Q: Which deployments are exposed?

Deployments using req_llm versions from 1.9.0 before 1.29.0 are exposed only when they use the OpenAI Responses, Realtime, or Codex WebSocket paths. HTTP streaming through Finch and HTTP/2 duplex sessions through Mint are not affected.

Q: What does an attacker need to exploit this issue?

An attacker must be able to act on the network path between the client and the WebSocket endpoint and present a TLS certificate that the client does not trust. Because certificate verification is disabled, the attacker can read and modify the WebSocket session, including its authorization bearer token.

Q: Can applications mitigate this by supplying custom CA certificates or TLS options?

No. The WebSocket client's option allowlist drops caller-supplied cacerts and ssl_options, so an application cannot enable certificate verification through those options.

Q: How can I determine whether a workload is affected?

Check whether it uses req_llm in the affected version range and whether it initiates OpenAI Responses, Realtime, or Codex WebSocket sessions. Workloads limited to Finch HTTP streaming or Mint HTTP/2 duplex sessions are not affected by this issue.

Published Oct 23, 2026

Updated

Improper Certificate Validation vulnerability in the WebSocket streaming client in agentjido reqllm 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/reqllm/streaming/websocketsession/client.ex starts WebSockex without TLS options, and WebSockex defaults to insecure: true, which connects with verify: :verifynone. The option allowlist also drops any caller-supplied cacerts or ssloptions, 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 reqllm: from 1.9.0 before 1.29.0.

Affected Software

1 affected component

hex/req_llm>=1.9.0<1.29.0

Event History

Oct 23, 2026

CVE Published

via MITRE·11:00 AM

Data Sourced

via MITRE·11:00 AM

DescriptionWeakness

Frequently Asked Questions

Which deployments are exposed?

Deployments using req_llm versions from 1.9.0 before 1.29.0 are exposed only when they use the OpenAI Responses, Realtime, or Codex WebSocket paths. HTTP streaming through Finch and HTTP/2 duplex sessions through Mint are not affected.

What does an attacker need to exploit this issue?

An attacker must be able to act on the network path between the client and the WebSocket endpoint and present a TLS certificate that the client does not trust. Because certificate verification is disabled, the attacker can read and modify the WebSocket session, including its authorization bearer token.

Can applications mitigate this by supplying custom CA certificates or TLS options?

No. The WebSocket client's option allowlist drops caller-supplied cacerts and ssl_options, so an application cannot enable certificate verification through those options.

How can I determine whether a workload is affected?

Check whether it uses req_llm in the affected version range and whether it initiates OpenAI Responses, Realtime, or Codex WebSocket sessions. Workloads limited to Finch HTTP streaming or Mint HTTP/2 duplex sessions are not affected by this issue.

CVE-2026-107685: WebSocket sessions do not verify TLS certificates, exposing API keys and OAuth tokens to on-path attackers

Affected Software

Event History

Frequently Asked Questions

Which deployments are exposed?

What does an attacker need to exploit this issue?

Can applications mitigate this by supplying custom CA certificates or TLS options?

How can I determine whether a workload is affected?

Company

Resources

Contact

Frequently Asked Questions

Which deployments are exposed?

What does an attacker need to exploit this issue?

Can applications mitigate this by supplying custom CA certificates or TLS options?

How can I determine whether a workload is affected?