ReqLLM: WebSocket sessions accepted any TLS certificate
ReqLLM's OpenAI WebSocket client accepted any TLS certificate, exposing the provider key in its authorization header.
· ReqLLM · Research by Neil Berkman
ReqLLM 1.9.0 through 1.28.0 did not verify TLS certificates on its OpenAI WebSocket sessions, so an on-path attacker could read the authorization header and the provider key it carries. Version 1.29.0 verifies peers.
01What happened
ReqLLM published advisory GHSA-6vww-5m28-f26v on October 22, 2026 and shipped the fix in v1.29.0 the same day. Neil Berkman reported that secure WebSocket connections in versions 1.9.0 through 1.28.0 accept any certificate. The flaw is tracked as CVE-2026-107685.
02How it works
The WebSocket client called WebSockex.start/4 without TLS settings, and WebSockex 0.5.1 defaults to insecure: true, which disables certificate verification. An attacker positioned on the network path can present any certificate, impersonate the server, and read or modify the session. The authorization header travels over that connection, so the bearer token in it is readable.
03Who is affected
Elixir applications on req_llm 1.9.0 through 1.28.0 that use the OpenAI Responses, Realtime or Codex WebSocket paths are exposed. HTTP streaming through Finch and the HTTP/2 session through Mint verify certificates and are not affected.
04What to do
Upgrade to req_llm 1.29.0, which enables peer verification, uses the system CA store, checks hostnames and fails closed when no trust store is available. Rotate any OpenAI key or OAuth token that an affected version carried over an untrusted network. Where upgrading must wait, avoid the WebSocket paths and use HTTP streaming.
Sources 3 links, all fetched
- 1github.comReqLLM Advisory
- 2github.comReqLLM 1.29.0
- 3github.comGitHub Advisory DB