# ReqLLM: WebSocket sessions accepted any TLS certificate

> ReqLLM's OpenAI WebSocket client accepted any TLS certificate, exposing the provider key in its authorization header.

- **Severity:** Medium: Real and reproducible, but needs unusual setup, user help or a narrow audience. Plan a fix.
- **Category:** Vulnerability
- **Published by:** ReqLLM
- **Disclosed:** 2026-10-22
- **CVE:** CVE-2026-107685
- **CVSS:** 7.4
- **Affects:** ReqLLM, req_llm (Hex)
- **Research by:** Neil Berkman
- **Primary source:** https://github.com/agentjido/req_llm/security/advisories/GHSA-6vww-5m28-f26v
- **Page:** https://theinjection.dev/items/req-llm-websocket-tls-verification/

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.

## What 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.

## How 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.

## Who 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.

## What 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.

## Quick facts

- **Affected:** req_llm 1.9.0 through 1.28.0
- **Fixed in:** 1.29.0, released October 22, 2026
- **CVE:** CVE-2026-107685
- **Scores:** 7.4 under CVSS 3.1 in the project advisory, 9.1 under CVSS 4.0 in the CVE record
- **Affected paths:** OpenAI Responses, Realtime and Codex WebSocket sessions
- **Found by:** Neil Berkman

## Sources

1. [ReqLLM Advisory](https://github.com/agentjido/req_llm/security/advisories/GHSA-6vww-5m28-f26v)
2. [ReqLLM 1.29.0](https://github.com/agentjido/req_llm/releases/tag/v1.29.0)
3. [GitHub Advisory DB](https://github.com/advisories/GHSA-w53j-6pxf-r2vw)