WebSocket sessions do not verify TLS certificates, exposing API keys and OAuth tokens to on-path attackers
- Published
- Last modified
- Status
- published
- Known exploitation
- Not listed in CISA KEV
- Fix
- Fixed in 1.29.0
- Public exploit
- None on Exploit-DB
Summary
The req_llm Elixir library's WebSocket streaming client (used for OpenAI Responses, Realtime, and Codex connections) does not verify TLS server certificates, so an attacker positioned on the network path can read and alter these sessions and capture API keys or OAuth bearer tokens sent in the authorization header. HTTP streaming and the HTTP/2 session paths in the same library are not affected.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original description
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.
Affected versions
- req_llm
From 1.9.0 · fixed in 1.29.0
- agentjido/req_llm
From a389d718640ceb2d541a8f540ab954cbf5ef8313 · fixed in c7264fc0217fbacfb5562234ff790b8e4462de76