CVE-2026-74836 in bandit
Summary
by MITRE • 08/21/2026
Allocation of Resources Without Limits or Throttling vulnerability in mtrudel bandit allows an unauthenticated remote attacker to pin an unbounded number of HTTP/2 stream processes indefinitely via connection-level flow control. When a stream's response body outruns the HTTP/2 connection-level send window (default 65,535 bytes, shared across all streams on the connection), Bandit.HTTP2.Connection queues the remaining bytes and a reply closure in pending_sends and the stream process blocks forever inside a synchronous call to the connection process. Nothing bounds that wait and nothing purges the queue: a client RST_STREAM for the blocked stream is delivered to its mailbox but never read while it is stuck inside the call, so cancelling frees nothing, and periodic PING frames keep the transport-level read timeout from ever firing. The equivalent block on the stream-level send window is already bounded at 15 seconds; the connection-level path had no such bound.
Each stalled stream pins its process, Plug state, and any resource the Plug holds across the blocked write, such as a pooled upstream connection in a reverse-proxy Plug. The attacker chooses any endpoint whose response exceeds the connection window (common for most non-trivial payloads), grants a generous stream-level window so only the connection window limits it, and keeps the connection alive with periodic PINGs; the primitive is repeatable across streams and connections at the cost of one idle socket each.
This issue affects bandit: from 0.3.4 before 1.12.5.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/21/2026
The vulnerability identified in Bandit, specifically within its HTTP/2 implementation prior to version 1.12.5, represents a critical resource exhaustion flaw classified under CWE-770 as Allocation of Resources Without Limits or Throttling. This issue stems from an asymmetry in how the framework handles flow control at different levels of the HTTP/2 protocol stack. While stream-level send windows are properly bounded with timeouts to prevent indefinite blocking, the connection-level send window lacks equivalent safeguards. When a response body exceeds the default connection-level send window size of 65,535 bytes, which is shared across all streams on a single TCP connection, Bandit.HTTP2.Connection queues the remaining data and associated reply closures in a pending_sends structure. Crucially, this operation causes the stream process to block indefinitely within a synchronous call to the connection process because there is no mechanism to purge the queue or unblock the waiting process under these specific conditions.
The operational impact of this flaw allows an unauthenticated remote attacker to perform a Denial of Service attack by pinning server resources without limit. By crafting requests that trigger responses larger than the connection window while maintaining generous stream-level windows, an attacker can force multiple streams into a blocked state on each active TCP connection. Each stalled stream consumes Erlang process memory and holds onto Plug state, including any upstream connections managed by reverse-proxy plugins such as pooled database or backend service links. This effectively leaks server-side resources, leading to increased latency for legitimate users, eventual crash of the BEAM virtual machine due to resource exhaustion, or complete unavailability of the service. The attack is particularly insidious because it requires only one idle socket per connection and can be repeated across numerous connections with minimal bandwidth consumption from the attacker's perspective.
Mitigation strategies must address both immediate remediation and long-term architectural resilience. The primary defense is upgrading Bandit to version 1.12.5 or later, where this specific flow control logic has been corrected to include proper bounds on connection-level waits. For environments unable to upgrade immediately, implementing rate limiting at the network perimeter can help mitigate the volume of concurrent connections an attacker might establish. Additionally, configuring web servers and load balancers to enforce strict timeouts on idle connections and monitoring for abnormal patterns in HTTP/2 stream creation rates can provide early detection signals. It is also advisable to review custom Plug implementations that manage upstream connections to ensure they do not inadvertently hold resources longer than necessary during such blocking events, although the root cause lies within Bandit's core handling of connection-level flow control rather than application logic.
From a threat intelligence perspective, this vulnerability aligns with ATT&CK technique T1499 Endpoint Denial of Service, specifically through resource exhaustion via protocol abuse. The attacker leverages legitimate HTTP/2 features like PING frames to keep the transport layer alive and avoid standard read timeouts, thereby bypassing basic network-level defenses that rely on connection inactivity detection. Security teams should prioritize patching this vulnerability due to its low complexity for exploitation and high impact on service availability. Regular audits of dependency versions against known CVE databases are essential to prevent similar resource management flaws from persisting in production environments.