CVE-2026-107685: ReqLLM's OpenAI WebSocket sessions skip TLS checks and can leak API keys
ReqLLM, an Elixir library for calling LLM APIs, didn't verify TLS certificates on its WebSocket connections from 1.9.0 through 1.28.0. An attacker on the network path can read the OpenAI API key or OAuth token in the authorization header and read or change prompts, responses and tool calls. Fixed in 1.29.0.
What it is
ReqLLM.Streaming.WebSocketSession.Client.start/3 started WebSockex without TLS options. WebSockex 0.5.1 defaults to insecure: true, which means verify: :verify_none, and ReqLLM's option allowlist dropped any cacerts or ssl_options a caller passed, so apps couldn't turn verification on.
The affected paths are OpenAI Responses WebSocket sessions, OpenAI Realtime sessions and OpenAI Codex WebSocket sessions, which send the API key or OAuth access token in the authorization header.
An attacker needs an on-path position, such as hostile Wi-Fi, a compromised network, or DNS or BGP interference. They can then steal the token and alter model output and tool calls before your app sees them. HTTP streaming through Finch and HTTP/2 through Mint verify certificates and aren't affected.
How to check
- Affected: req_llm (Hex) 1.9.0 through 1.28.0.
- You are exposed if your app uses ReqLLM's OpenAI Responses, Realtime or Codex WebSocket features.
How to fix
- Upgrade req_llm to 1.29.0 or later, which verifies the peer and hostname using the system certificate store and fails closed if it isn't available.
- If you can't upgrade, stop using the WebSocket paths and use HTTP streaming. Consider rotating OpenAI keys or tokens that were used over untrusted networks.
mix deps | grep req_llm Sources
- criticalLiteLLM 1.107.0 on PyPI and Docker was malware: a credential stealer that runs whenever Python starts
- criticalMalicious npm packages posing as ChatGPT, Claude and Codex setup tools
- criticalOpenCode Console breach exposed saved provider API keys
- highOWASP LLM01:2025: prompt injection is the top LLM app risk