CVE-2026-107685: req_llm: TLS verification disabled in OpenAI WebSockets

AWAITING NVD

Published October 23, 2026

CISO Take

req_llm, an Elixir LLM client library, connects to OpenAI over WebSockets without verifying TLS certificates (WebSockex defaults to verify_none), and it strips any caller-supplied TLS options so applications cannot enable verification themselves. An on-path attacker can therefore read and modify OpenAI Responses, Realtime and Codex sessions and capture the API key or OAuth bearer token sent in the authorization header. No public exploit, Nuclei template or KEV listing exists and EPSS is not yet available, but the attack needs only a network position, and the stolen credentials give direct access to your OpenAI account and spend. Dependent counts are unknown, so inventory Elixir services that use req_llm 1.9.0 to 1.28.x with WebSocket streaming. Upgrade to 1.29.0 or later, rotate any OpenAI keys or OAuth tokens used over these paths, and review OpenAI usage logs for anomalies. HTTP streaming via Finch and the Mint HTTP/2 duplex session are not affected.

Sources:NVDGitHub Advisorycna.erlef.orgosv.devATLAS

What is the risk?

Severity is rated critical, with no CVSS vector or EPSS score published yet. Exploitation requires an on-path position (hostile Wi-Fi, a compromised proxy or router, DNS or BGP hijack, or a rogue egress gateway), which raises attack complexity, but once in position it is trivial because the client accepts any certificate. Impact covers confidentiality and integrity: credential theft plus tampering with prompts and model responses. Exposure is limited to deployments that use the OpenAI WebSocket paths (Responses, Realtime, Codex) in req_llm 1.9.0 up to but excluding 1.29.0. No known active exploitation or public PoC at this time.

How does the attack unfold?

Initial Access

Attacker gains an on-path network position between the req_llm client and OpenAI.

AML.T0049

Interception

The client accepts the attacker's untrusted TLS certificate because verification is disabled, exposing the WebSocket session.

AML.T0096

Credential Theft

Attacker extracts the OpenAI API key or OAuth bearer token from the authorization header.

AML.T0091.000

Impact

Attacker reads or alters prompts and responses and reuses the token for unauthorized OpenAI access and spend.

AML.T0048.000

Initial Access

Attacker gains an on-path network position between the req_llm client and OpenAI.

AML.T0049

Interception

The client accepts the attacker's untrusted TLS certificate because verification is disabled, exposing the WebSocket session.

AML.T0096

Credential Theft

Attacker extracts the OpenAI API key or OAuth bearer token from the authorization header.

AML.T0091.000

Impact

Attacker reads or alters prompts and responses and reuses the token for unauthorized OpenAI access and spend.

AML.T0048.000

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
OpenAI Node	npm	—	No patch
11.2K1.8K dependentsPushed 7d ago56% patched~139d to patchFull package profile →
agentjido/req_llm	—	—	No patch
req_llm	—	—	No patch

How severe is it?

CVSS 3.1

N/A

EPSS

0.3%

chance of exploitation in 30 days

Higher than 20% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What should I do?

1 step

1) Upgrade req_llm to 1.29.0 or later (patch commits a389d71 and c7264fc). 2) Rotate OpenAI API keys and OAuth tokens that were used over WebSocket paths on affected versions, and revoke old ones. 3) Until patched, switch to the HTTP streaming (Finch) or HTTP/2 duplex (Mint) transports, which verify certificates. 4) Restrict egress so WebSocket traffic to OpenAI goes only through trusted networks, and avoid running it over untrusted Wi-Fi or unmanaged proxies. 5) Detect: check mix.lock and SBOMs for req_llm versions from 1.9.0 to below 1.29.0, review OpenAI usage dashboards for unexpected IPs, models or spend, and monitor for TLS interception or unexpected certificates on egress. 6) Add a dependency-scanning rule for this GHSA (GHSA-6vww-5m28-f26v).

How is it classified?

Data LeakageAuth BypassSupply ChainFrameworkAPIAML.T0010.001- AI Software AML.T0055- Unsecured Credentials AML.T0091.000- Application Access Token AML.T0096- AI Service API

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art. 15-Accuracy, robustness and cybersecurity

ISO 42001

A.10.3-Suppliers

NIST AI RMF

MANAGE 2.3-Response to previously unknown risks and supply chain risk management

OWASP LLM Top 10

LLM02-Sensitive Information DisclosureLLM03-Supply Chain

Frequently Asked Questions

What is CVE-2026-107685?

Is CVE-2026-107685 actively exploited?

No confirmed active exploitation of CVE-2026-107685 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-107685?

1) Upgrade req_llm to 1.29.0 or later (patch commits a389d71 and c7264fc). 2) Rotate OpenAI API keys and OAuth tokens that were used over WebSocket paths on affected versions, and revoke old ones. 3) Until patched, switch to the HTTP streaming (Finch) or HTTP/2 duplex (Mint) transports, which verify certificates. 4) Restrict egress so WebSocket traffic to OpenAI goes only through trusted networks, and avoid running it over untrusted Wi-Fi or unmanaged proxies. 5) Detect: check mix.lock and SBOMs for req_llm versions from 1.9.0 to below 1.29.0, review OpenAI usage dashboards for unexpected IPs, models or spend, and monitor for TLS interception or unexpected certificates on egress. 6) Add a dependency-scanning rule for this GHSA (GHSA-6vww-5m28-f26v).

What systems are affected by CVE-2026-107685?

This vulnerability affects the following AI/ML architecture patterns: LLM API clients, Agent frameworks, Realtime/voice AI pipelines, Streaming inference integrations.

What is the CVSS score for CVE-2026-107685?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

LLM API clientsAgent frameworksRealtime/voice AI pipelinesStreaming inference integrations

MITRE ATLAS Techniques

AML.T0010.001AI Software

AML.T0055Unsecured Credentials

AML.T0091.000Application Access Token

AML.T0096AI Service API

Compliance Controls Affected

EU AI Act: Art. 15

ISO 42001: A.10.3

NIST AI RMF: MANAGE 2.3

OWASP LLM Top 10: LLM02, LLM03

What are the technical details?

Original Advisory

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.

Exploitation Scenario

An attacker positions themselves on the network path of a server or developer workstation running an Elixir agent built on req_llm, for example through a compromised corporate proxy or a rogue access point. When the app opens an OpenAI Realtime or Responses WebSocket, the attacker presents a self-signed certificate, which the client accepts because verification is disabled. They proxy the session to OpenAI, harvest the bearer token from the authorization header, and log all prompts and responses. They can also rewrite model responses or tool-call instructions in flight to manipulate the agent, then reuse the stolen token later for their own API usage.

Weaknesses (CWE)

CWE-295Improper Certificate Validation CWE-295Improper Certificate Validation

CWE-295 — Improper Certificate Validation: The product does not validate, or incorrectly validates, a certificate.

[Architecture and Design, Implementation] Certificates should be carefully managed and checked to assure that data are encrypted with the intended owner's public key.
[Implementation] If certificate pinning is being used, ensure that all relevant properties of the certificate are fully validated before the certificate is pinned, including the hostname.

Source: MITRE CWE corpus.