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.
Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).
| Vendor | Product | Default status | Versions | ||||||
|---|---|---|---|---|---|---|---|---|---|
| mtrudel | bandit | unaffected |
|
||||||
| mtrudel | bandit | unaffected |
|
No data.
No data.
No data.
No advisories yet.
Solution
No solution given by the vendor.
Workaround
No workaround given by the vendor.
Fri, 24 Jul 2026 18:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| 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. | |
| Title | Quadratic CPU blow-up reassembling fragmented WebSocket messages in Bandit | |
| First Time appeared |
Mtrudel
Mtrudel bandit |
|
| Weaknesses | CWE-407 | |
| CPEs | cpe:2.3:a:mtrudel:bandit:*:*:*:*:*:*:*:* | |
| Vendors & Products |
Mtrudel
Mtrudel bandit |
|
| References |
| |
| Metrics |
cvssV4_0
|
Projects
Sign in to view the affected projects.
MITRE
Status: PUBLISHED
Assigner: EEF
Published:
Updated: 2026-07-24T17:09:09.552Z
Reserved: 2026-07-22T13:55:59.401Z
Link: CVE-2026-65623
Vulnrichment
Updated: 2026-07-24T17:09:03.715Z
NVD
No data.
Redhat
No data.
OpenCVE Enrichment
No data.