CVE-2026-114213 in bandit
Summary
by MITRE • 10/26/2026
Allocation of Resources Without Limits or Throttling vulnerability in the WebSocket fragment reassembly of mtrudel bandit allows an unauthenticated remote attacker to exhaust server memory via a fragmented message made of many 1-byte continuation frames.
Bandit.WebSocket.Connection checks max_fragmented_message_size against the payload bytes received, but keeps every non-final continuation frame as a new list cell around its own binary, and nothing limits the number of fragments. A 1-byte fragment costs 7 bytes on the wire but about 150 to 170 bytes of server memory, so one connection can hold about 150 times the configured limit, roughly 1.2 to 1.4 GB at the default 8 MB. Ping frames between fragments keep the connection alive past the idle timeout.
This issue affects bandit: from 1.11.0 before 1.14.0.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/26/2026
The vulnerability identified in Bandit, specifically within its WebSocket implementation prior to version 1.14.0, represents a critical resource exhaustion flaw rooted in the handling of fragmented messages during reassembly. This issue is classified under CWE-770 as an Allocation of Resources Without Limits or Throttling. The core technical failure lies in how the Bandit.WebSocket.Connection module processes incoming WebSocket frames that are split into multiple fragments. While the library correctly checks the cumulative payload size against a configured maximum fragmented message size limit, it fails to enforce this constraint on the number of individual frame structures retained in memory during the reassembly process. Specifically, every non-final continuation frame is allocated as a new list cell containing its binary data, creating an unbounded accumulation of objects until the final fragment arrives or the connection closes.
The operational impact of this flaw is severe due to the significant disparity between network overhead and server-side memory consumption. A single one-byte WebSocket fragment incurs approximately seven bytes on the wire but consumes roughly 150 to 170 bytes in server memory when processed by Bandit's internal data structures. This inefficiency allows an unauthenticated remote attacker to trigger a Denial of Service condition with minimal bandwidth usage. By sending a sequence of many one-byte continuation frames, an attacker can cause the server to allocate hundreds of megabytes or even over a gigabyte of RAM per connection. At the default configuration limit of eight megabytes for fragmented messages, this vulnerability enables a single malicious client to consume approximately 150 times that configured limit, effectively exhausting available memory resources and potentially crashing the application or degrading service availability for legitimate users.
To maintain persistence during the attack, adversaries can utilize WebSocket ping frames interspersed between the fragment sequences. These keep-alive messages prevent the connection from being terminated by idle timeouts, allowing the attacker to sustain the resource drain over an extended period without needing to re-establish connections repeatedly. This technique aligns with ATT&CK tactic T1498 Network Denial of Service and specifically relates to sub-techniques involving volumetric attacks or protocol abuse that target application-layer resources rather than just network bandwidth. The vulnerability affects all versions of Bandit from 1.11.0 up to, but not including, version 1.14.0, where the underlying WebSocket handling logic was revised to address these structural inefficiencies and enforce stricter limits on fragment counts or memory allocation patterns during reassembly operations.
Mitigation strategies primarily involve upgrading to a patched version of Bandit that resolves this architectural flaw in the WebSocket handler. For environments where immediate patching is not feasible, deploying a Web Application Firewall with deep packet inspection capabilities can help detect and block anomalous patterns of fragmented WebSocket traffic characterized by an unusually high number of small continuation frames from a single source IP address. Additionally, implementing strict rate limiting on new WebSocket connections and monitoring server memory usage per connection instance can provide early warning indicators for such exploitation attempts. Security architects should also consider enforcing stricter limits on the maximum number of fragments allowed in a reassembly buffer as part of defense-in-depth measures to prevent similar resource exhaustion vulnerabilities in other websocket libraries or custom implementations that may share this design pattern.