Client-chosen HPACK encoder table size is applied uncapped, growing per-connection state with every response in Bandit
What fixes it
A fixed version on one release line is not the upgrade target for every line. Check your exact version and any vendor backports.
Description
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.
Text from CVE List
Affected versions 2
- banditaffected: 0.3.6 before 1.14.0CVE List
- banditaffected: 0e68313fab9d204257ebad5c447e4cd9cea8e0ea before 220b9dfd27f9a21305be2afc75cbe585ddc24e7aCVE List
References 5
- github.com/mtrudel/bandit/commit/0e68313fab9d204257ebad5c447e4cd9cea8e0eaFixvia CVE List
- github.com/mtrudel/bandit/commit/220b9dfd27f9a21305be2afc75cbe585ddc24e7aFixvia CVE List
- github.com/mtrudel/bandit/security/advisories/GHSA-47x4-3fxf-82frAdvisoryvia CVE List
- cna.erlef.org/cves/CVE-2026-110499.htmlReferencevia CVE List
- osv.dev/vulnerability/EEF-CVE-2026-110499Referencevia CVE List