CVE-2026-116078 in bandit
Summary
by MITRE • 10/28/2026
Allocation of Resources Without Limits or Throttling vulnerability in the HTTP/2 request body reader of mtrudel bandit allows an unauthenticated remote attacker to exhaust server memory via a request body sent as many 1-byte DATA frames.
do_read_data/5 in lib/bandit/http2/stream.ex keeps every DATA frame payload as its own list element until the read returns. The :length option of read_body/2 counts body bytes, not frames, so a body of 1-byte frames costs a list cell and a binary term per byte. Interleaving the frames across up to 500 concurrent streams per connection keeps each stream consuming its frames as they arrive; in the reporter's test, 100 streams held 25 to 40 MiB of stream process memory for 5 MB sent. Only routes whose Plug reads the request body are affected, which includes any route behind Plug.Parsers.
This issue affects bandit: from 0.3.1 before 1.14.1.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/28/2026
The vulnerability identified in Bandit, specifically within its HTTP/2 implementation prior to version 1.14.1, represents a critical resource exhaustion flaw rooted in the inefficient handling of request body data frames. This issue is classified under CWE-770 as an Allocation of Resources Without Limits or Throttling. The core technical defect resides in the do_read_data function within the lib/bandit/http2/stream.ex module, which processes incoming HTTP/2 DATA frames for a given stream. Instead of buffering or aggregating these payloads efficiently, the implementation appends every individual DATA frame payload as a distinct element to an internal list structure that persists until the read operation completes and returns control to the application logic. This design choice creates a direct correlation between the number of discrete network packets received and the memory footprint allocated by the server process for handling that specific request stream.
The severity of this vulnerability is significantly amplified by the mechanics of HTTP/2 multiplexing, which allows multiple logical streams to be interleaved over a single TCP connection. An unauthenticated remote attacker can exploit this behavior by fragmenting a relatively small total payload into thousands or millions of one-byte DATA frames. Because Bandit maintains separate list elements for each frame regardless of size, the memory overhead per byte becomes substantial due to the allocation costs associated with Erlang terms and list nodes. In practical testing scenarios involving up to 500 concurrent streams per connection, sending just five megabytes of data fragmented into one-byte chunks resulted in stream processes consuming between twenty-five and forty megabytes of memory each. This disproportionate ratio means that a modest volume of network traffic can rapidly deplete the available heap space of individual BEAM virtual machine workers responsible for handling these requests.
The operational impact of this flaw is severe, leading to potential denial-of-service conditions where server resources are exhausted without any need for authentication or complex exploitation techniques beyond standard HTTP/2 framing capabilities. The vulnerability specifically affects routes that invoke Plug components capable of reading the request body, which includes most web applications utilizing Plug.Parsers for content negotiation and parameter extraction. As these processes consume excessive memory to store fragmented frame data, they may trigger garbage collection cycles excessively or crash due to out-of-memory errors, thereby destabilizing the entire server instance if multiple such streams are active simultaneously. This aligns with ATT&CK technique T1498 Network Denial of Service, as it involves overwhelming a resource to make it unavailable to legitimate users through inefficient resource consumption rather than simple bandwidth saturation.
Mitigation strategies must focus on upgrading Bandit to version 1.14.1 or later, where the internal handling of DATA frames has been optimized to prevent this linear memory growth relative to frame count. For environments unable to patch immediately, administrators should consider implementing rate limiting at the network perimeter or load balancer level to restrict the number of concurrent HTTP/2 streams per connection and limit the maximum size of request bodies accepted by the application layer. Additionally, configuring web servers to reject excessively fragmented requests or enforcing stricter limits on frame sizes can help mitigate the risk until a permanent code-level fix is deployed. It is crucial for development teams reviewing their dependency chains to ensure that all instances of Bandit are updated, as this vulnerability persists across versions from 0.3.1 up to but not including 1.14.1.