CVE-2026-110499 in bandit
Summary
by MITRE • 10/26/2026
Allocation of Resources Without Limits or Throttling vulnerability in the HTTP/2 implementation of mtrudel bandit allows an unauthenticated remote attacker to grow per-connection memory and CPU cost without bound via a large SETTINGS_HEADER_TABLE_SIZE. Bandit resizes its HPACK encoder table to whatever size the client advertises, up to 2^32-1 bytes, and indexes response headers into it. Because responses carry distinct values such as date or content-length, nothing is evicted and the table grows with every response for the life of the connection, while each lookup scans it linearly.
The SETTINGS handling in Bandit.HTTP2.Connection (lib/bandit/http2/connection.ex) passes remote_settings.header_table_size to HPAX.resize/2 with no server-side cap, and encode_headers encodes every response header as :store. Serving N responses on one connection therefore costs O(N²) CPU in the connection process.
This issue affects bandit: from 0.3.6 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 involves an allocation of resources without limits or throttling within the HTTP/2 implementation of Bandit, a web server for Elixir. This flaw allows an unauthenticated remote attacker to cause a denial of service by consuming excessive memory and CPU resources on the target system. The attack vector centers on the manipulation of the SETTINGS_HEADER_TABLE_SIZE parameter during the HTTP/2 connection establishment phase. By advertising an extremely large value for this setting, specifically up to the maximum integer limit of 4 gigabytes minus one byte, the attacker forces the server's HPACK encoder table to resize accordingly. This behavior bypasses any internal safeguards that would normally restrict memory allocation based on expected traffic patterns or system capabilities.
The technical root cause lies in how Bandit handles remote settings within its HTTP/2 connection module. When a client sends a SETTINGS frame specifying a new header table size, the server passes this value directly to the HPAX resize function without applying any upper bound validation. Consequently, the server allocates memory proportional to the attacker's request rather than adhering to reasonable operational limits. Furthermore, because every response includes distinct headers such as date stamps or content-length values that do not match previously seen entries in the dynamic table, no compression gains are achieved through deduplication. Instead, each new header is stored in the ever-expanding table without eviction mechanisms kicking in effectively due to the sheer scale of the allocated space relative to typical usage patterns.
The operational impact of this vulnerability is severe and manifests as both memory exhaustion and significant CPU degradation. As the connection persists, the server continues to index response headers into the massive HPACK table for every single request served over that specific connection. This results in a quadratic time complexity relationship between the number of responses sent and the computational cost incurred by the connection process. Specifically, each lookup within this unbounded structure requires linear scanning relative to its current size, meaning that as N responses are processed, the CPU cost scales with O(N squared). An attacker can exploit this by maintaining long-lived connections and sending numerous requests, thereby exhausting server memory through continuous allocation and crippling performance through excessive computational overhead.
This issue affects Bandit versions ranging from 0.3.6 up to but not including version 1.14.0. To mitigate this risk, it is imperative for administrators to upgrade to a patched version of Bandit where the HTTP/2 implementation includes proper validation and capping of remote settings values. Additionally, implementing network-level rate limiting or connection duration limits can provide an additional layer of defense against such resource exhaustion attacks. From a classification perspective, this vulnerability aligns with CWE-770 regarding allocation of resources without limits or throttling, which describes scenarios where insufficient input validation leads to excessive consumption of system resources. In terms of the MITRE ATT&CK framework, this behavior corresponds to techniques associated with Denial of Service, specifically those involving resource exhaustion through protocol manipulation rather than volumetric flooding.