AgentJido ReqLLM CVE-2026-107685

Requires two things together: (1) the application must use one of the affected OpenAI WebSocket paths - Responses in WebSocket mode (provider_options: [openai_stream_transport: :websocket]), Realtime sessions (ReqLLM.OpenAI.Realtime), or the Codex WebSocket path - on req_llm 1.9.0 through 1.28.0; and (2) the attacker must hold an on-path network position (compromised network, hostile Wi-Fi, or DNS/BGP interference) to substitute a certificate the client would otherwise reject. Limiting factors: default HTTP streaming via Finch and the HTTP/2 duplex session via Mint verify certificates and are NOT affected, so applications not opting into the WebSocket transports are unexposed; and because the allowlist dropped TLS options, affected versions could not be configured to turn verification on, meaning the only reliable mitigation is upgrading to 1.29.0 (or avoiding the affected WebSocket paths).

This is a genuine high-priority issue, corroborated across multiple independent signals rather than a high-CVSS-but-low-real-risk case. The CWE-295 improper certificate validation flaw is confirmed by the vendor GHSA advisory (GHSA-6vww-5m28-f26v), the Erlang Ecosystem Foundation CNA (reporter EEF), and OSV, and a vendor patch is available (fixed in 1.29.0). The input CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H) correctly captures the shape: network-reachable, no authentication, but with an attack requirement (AT:P) - the attacker must hold an on-path position (compromised network, hostile Wi-Fi, DNS/BGP interference). That AT:P requirement is the single biggest real-world limiter and should be weighed against the raw 9.1: this is not mass-scannable remote code execution but a man-in-the-middle condition. The vuln.today decision label is act_now, which - combined with confirmed token/secret exposure (API keys, OAuth access tokens) and the ability to modify model output and tool calls - justifies prompt remediation. Contrasting signals: no EPSS score is provided and the CVE is NOT in CISA KEV, and no public exploit reference appears in the input, so there is no evidence of active exploitation or widespread automated attacks; the urgency here derives from impact severity and the act_now label, not from observed in-the-wild activity. The confidentiality AND integrity impact (read and alter the session) makes this materially worse than a pure eavesdropping bug.

A user of an application built on req_llm (1.9.0-1.28.0) using the OpenAI Responses, Realtime, or Codex WebSocket transport connects over a network an attacker controls or can intercept (e.g., hostile Wi-Fi or DNS/BGP manipulation). Because the WebSocket client connects with verify: :verify_none, the attacker terminates the wss:// connection with an untrusted certificate the handshake nonetheless accepts, then reads the authorization: Bearer token and relays/alters the session. No public exploit code is identified at time of analysis, but reproduction is straightforward per the advisory (point the client at a self-signed TLS WebSocket endpoint).