CVE-2026-108529 in bandit
Summary
by MITRE • 10/26/2026
Inefficient Algorithmic Complexity vulnerability in the HTTP/2 implementation of mtrudel bandit allows an unauthenticated remote attacker to exhaust server CPU via small SETTINGS or connection-level WINDOW_UPDATE frames. The attacker opens thousands of streams whose responses block on the connection send window, then sends cheap frames that each make the server walk the whole queue of blocked sends. In the reporter's run, with 3,000 blocked streams a single 9-byte SETTINGS frame took 133 ms to process.
do_pending_sends/2 in lib/bandit/http2/connection.ex retries every queued send and, before each retry, removes that entry from the queue with List.delete/2, so one frame costs O(n²) list operations for n blocked streams. max_concurrent_streams defaults to :infinity, so the attacker chooses n.
This issue affects bandit: from 0.3.4 before 1.14.0.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/26/2026
The vulnerability identified in the HTTP/2 implementation of Bandit represents a critical inefficiency in algorithmic complexity that enables denial-of-service attacks through resource exhaustion. Specifically, this flaw allows an unauthenticated remote attacker to consume excessive server CPU cycles by exploiting the handling of small SETTINGS or connection-level WINDOW_UPDATE frames. The attack vector relies on opening thousands of concurrent streams where the responses are blocked due to hitting the connection send window limits. Once these streams are queued for transmission but unable to proceed because of flow control constraints, an attacker can transmit minimal-sized frames that trigger a disproportionate amount of server-side processing logic. This behavior effectively turns small network inputs into significant computational burdens, leading to service degradation or complete unavailability for legitimate users sharing the same server resources.
The technical root cause lies in the implementation of the do_pending_sends function within the lib/bandit/http2/connection.ex module. When this function processes queued sends, it iterates through every blocked stream and attempts to retry transmission. Crucially, before each retry attempt, the system removes the corresponding entry from the queue using List.delete/2. In Erlang/Elixir, lists are implemented as linked structures where deletion is not a constant-time operation; instead, removing an element requires traversing the list up to that point. Consequently, when processing n blocked streams, this loop results in O(n squared) complexity for list operations. As the number of blocked streams increases, the computational cost grows quadratically rather than linearly. This design flaw means that a single small frame can force the server to perform thousands or even millions of redundant traversal and deletion steps if many streams are waiting on the send window.
The operational impact of this vulnerability is severe due to default configuration settings in Bandit. The max_concurrent_streams parameter defaults to infinity, which removes any inherent upper bound on the number of concurrent streams an attacker can open. By leveraging this setting, a malicious actor can create thousands of blocked streams with minimal effort and network bandwidth usage. Empirical testing has demonstrated that with three thousand blocked streams, processing a single nine-byte SETTINGS frame takes approximately 133 milliseconds. This latency spike is significant in high-throughput environments where sub-millisecond response times are often expected. The cumulative effect of such delays across multiple connections can lead to thread pool exhaustion or CPU saturation, effectively rendering the application inaccessible without requiring large payloads or complex exploitation techniques.
From a classification perspective, this vulnerability aligns with CWE-400, which describes uncontrolled resource consumption leading to denial of service. It also relates to CWE-756: Missing Explanation of Unusual Behavioral Condition, as the inefficient handling of queued sends is not an obvious security failure but rather a performance anti-pattern that has security implications under specific load conditions. In terms of attack tactics, this falls under MITRE ATT&CK technique T1499: Endpoint Denial of Service, specifically involving resource exhaustion via application layer protocols. The attacker utilizes low-cost network interactions to trigger high-cost server-side processing, bypassing traditional volume-based DDoS detection mechanisms that look for large data transfers.
Mitigation strategies must focus on limiting the impact of this algorithmic inefficiency until a patched version is deployed. Administrators should immediately configure max_concurrent_streams to a reasonable finite value based on expected application behavior and available server resources. This limits the maximum number of blocked streams an attacker can create, thereby capping the potential O(n squared) complexity at a manageable level. Additionally, implementing rate limiting or connection throttling mechanisms can help detect and block anomalous patterns of stream creation that precede this type of attack. Upgrading to Bandit version 1.14.0 or later is essential as it addresses the underlying implementation flaw in the HTTP/2 connection handling logic. Until then, monitoring for spikes in CPU usage correlated with small frame sizes can serve as an early warning indicator for active exploitation attempts.