CVE-2026-107685

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.

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.

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.

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.

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.

Summary

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.

Details

1. Entry points. ReqLLM.Providers.OpenAI.WebSocket.responses_url/2 and realtime_url/2, and the Codex provider's codex_websocket_url/1, turn the provider base URL into a wss:// URL and start ReqLLM.Streaming.WebSocketSession with an authorization header that carries the OpenAI API key or the OAuth access token.

2. Missing TLS options. WebSocketSession.init/1 passes only the headers and the timeouts to WebSocketSession.Client.start/3, and the allowlist in start/3 forwards only name, debug, async, handle_initial_conn_failure, and the socket timeouts to WebSockex.start/4. No insecure, cacerts, or ssl_options value reaches WebSockex, and a caller cannot inject one.

3. Insecure default. WebSockex 0.5.1 sets insecure: true when the option is absent and opens the wss:// connection through :ssl.connect/4 with verify: :verify_none. Any certificate completes the handshake, so an attacker who terminates TLS on the path receives the upgrade request with the bearer token and every frame of the session, and can rewrite frames in either direction.

Proof of concept

1. Start a TLS endpoint on localhost with a self-signed certificate chain that no trust store contains, and let it answer the WebSocket upgrade with 101 Switching Protocols.
2. On a vulnerable version, call ReqLLM.Streaming.WebSocketSession.start_link/2 with wss://localhost:<port>/socket and headers: [{"authorization", "Bearer <token>"}], then await_connected/2.
3. await_connected/2 returns :ok, the endpoint completes the TLS handshake, and the endpoint receives the upgrade request carrying the bearer token. On 1.29.0 the same call returns {:error, %WebSockex.ConnError{original: {:tls_alert, {:unknown_ca, _}}}} and the endpoint never sees the request.

Impact

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 and the full session content, and can alter model output and tool calls before the application acts on them. Every application that uses the OpenAI Responses, Realtime, or Codex WebSocket paths is affected.

Workarounds

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.