CVE-2026-109584 in bandit
Summary
by MITRE • 10/26/2026
Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in the HTTP/2 implementation of mtrudel bandit allows an unauthenticated remote attacker to exhaust server memory via a small HPACK-compressed HEADERS block. The block stores one large cookie value in the HPACK dynamic table and then references it tens of thousands of times with 1-byte indexed fields. In the reporter's run, a 49 KB block made a server with default settings allocate a 183 MB cookie binary before any application code ran, and every concurrent stream can repeat the cost.
Bandit.HTTP2.Connection caps only the compressed block (max_header_block_size), and its check of the decoded list against max_header_list_size never fires because that setting defaults to :infinity. combine_cookie_crumbs/1 in lib/bandit/http2/stream.ex then joins every crumb into one binary.
This issue affects bandit: from 0.3.3 before 1.14.0.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/26/2026
The vulnerability identified as Improper Handling of Highly Compressed Data, specifically manifesting as a data amplification attack within the HTTP/2 implementation of Bandit, represents a critical resource exhaustion risk for web servers relying on this library. This flaw allows an unauthenticated remote attacker to trigger significant memory consumption on the server side by exploiting the interaction between HPACK compression and header processing logic. The core mechanism involves sending a deceptively small HTTP/2 HEADERS block that leverages the dynamic table features of HPACK to achieve massive expansion upon decompression. By storing a single large cookie value in the dynamic table and then referencing it tens of thousands of times using one-byte indexed fields, an attacker can create a scenario where the compressed payload is minimal but the resulting decoded data is enormous. In practical demonstrations, a compressed block of only 49 kilobytes resulted in the server allocating approximately 183 megabytes of memory for cookie processing alone, occurring before any application-level code was executed. This disproportionate ratio between input size and resource consumption enables efficient denial-of-service attacks that can degrade service availability or cause complete system failure through out-of-memory conditions.
The technical root cause lies in how Bandit manages header limits during the HTTP/2 connection lifecycle. The library implements a cap on the compressed block size via the max_header_block_size setting, which successfully restricts the initial network payload from exceeding a certain threshold. However, this check is insufficient because it does not account for the expansion factor inherent to HPACK compression when dynamic table references are heavily utilized. Furthermore, Bandit’s validation of the decoded header list against the max_header_list_size configuration fails to trigger in default configurations because that setting defaults to infinity. Consequently, there is no upper bound on the size of the decomposed headers before they are processed by application logic. The function combine_cookie_crumbs/1 located in lib/bandit/http2/stream.ex aggregates all individual header fragments into a single binary object without verifying if this aggregated structure exceeds reasonable memory limits. This design oversight means that every concurrent stream can independently trigger this massive allocation, multiplying the impact across multiple connections and rapidly exhausting server resources even under moderate load conditions.
From an operational perspective, this vulnerability poses a severe threat to service stability and availability. Since the attack vector requires no authentication, any external actor on the network can exploit it by crafting malicious HTTP/2 requests with optimized HPACK headers. The ability to repeat this cost across every concurrent stream means that even low-bandwidth attackers can overwhelm high-capacity servers if they maintain sufficient connection concurrency. This type of resource exhaustion directly impacts the confidentiality, integrity, and availability triad, primarily affecting availability by rendering legitimate users unable to access services due to server unresponsiveness or crashes. The lack of early validation against decompressed size limits creates a blind spot in standard DDoS mitigation strategies that often focus on input rate limiting rather than content expansion ratios.
To mitigate this vulnerability, immediate updates to the Bandit library are required for all versions from 0.3.3 up to but not including 1.14.0, where these issues have been addressed through stricter validation of decompressed header sizes and more robust handling of cookie aggregation logic. Administrators running affected versions should prioritize upgrading to a patched release as the primary remediation step. In environments where immediate patching is not feasible, temporary mitigations may include configuring reverse proxies or load balancers in front of Bandit servers to enforce stricter limits on HTTP/2 header block sizes and decompressed content lengths before requests reach the application server. Additionally, explicitly setting max_header_list_size to a finite value lower than available memory can provide an additional layer of defense by ensuring that the decoded list is validated against a concrete threshold rather than defaulting to infinity. Monitoring for unusual spikes in memory usage correlated with HTTP/2 traffic patterns can also aid in early detection and response to active exploitation attempts.
This vulnerability aligns with CWE-409, which describes Improper Handling of Highly Compressed Data (Data Amplification), highlighting the failure to adequately control resource consumption resulting from decompression operations. It is further categorized under MITRE ATT&CK technique T1498.002, Network Denial of Service via Resource Exhaustion by Application Layer Protocol Abuse, as it exploits specific protocol features for denial-of-service purposes. Understanding these classifications helps in aligning defensive measures with industry-standard frameworks and ensures that security controls are designed to address both the technical flaw and its strategic impact on system resilience.