SEPTEMBER 20, 2026
Live Feed
Back to database
Case File

CVE-2026-65623

HIGH · CVSS 8.7 EPSS 0.39% Public Exploit

Source: NVD + CISA KEV + EPSS · Published 2026-07-24 · Last synced 2026-08-23

CyberRota Analysis

AI-Generated

The mtrudel Bandit framework is vulnerable to a denial of service attack due to an inefficient algorithmic complexity in its WebSocket fragment reassembly process, allowing unauthenticated attackers to exhaust CPU resources. By sending numerous small continuation frames, an attacker can significantly degrade server performance, potentially denying service to legitimate users for extended periods. Organizations using Bandit versions 1.11.0 through 1.12.0 should prioritize patching to mitigate this risk.

Public Exploit Signal

A public exploit, PoC, GitHub repository or Metasploit reference was detected for this CVE.

Note: these links are listed for security research and verification purposes only.

CVE
CVE-2026-65623
Severity
HIGH
CVSS
8.7
EPSS
0.39%

Original NVD Description

Inefficient Algorithmic Complexity vulnerability in mtrudel bandit allows unauthenticated remote denial of service via CPU exhaustion during WebSocket fragment reassembly. The size guard 'Elixir.Bandit.WebSocket.Connection':oversize_message?/2 called from handle_frame/3 in lib/bandit/websocket/connection.ex appends each non-final continuation frame to a left-nested iolist and then re-measures the entire accumulated buffer with IO.iodata_length/1 on every frame. Because the buffer grows by one element per frame and is fully re-traversed each time, reassembly work is quadratic (O(n^2)) in the number of continuation frames. The max_fragmented_message_size limit (default 8 MB) bounds total bytes but not frame count, and each frame can carry as little as one payload byte, so an attacker can send millions of tiny continuation frames using modest bandwidth to pin a CPU core for minutes to hours. Many concurrent connections can starve the whole server of CPU, denying service to legitimate users. The WebSocket read timeout does not help, because it is an idle timeout evaluated between reads and cannot preempt the synchronous reassembly work spent inside a single callback. This issue affects bandit: from 1.11.0 before 1.12.1.