HTTP/2 cookie crumb join expands a small HPACK header block into an unbounded allocation in Bandit

Overview

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.

Affected

• bandit >= 0.3.3 < 1.14.0
• mtrudel/bandit >= 44bf969cd59851622fb6ee4d16227fbc39a77fb4 < 220b9dfd27f9a21305be2afc75cbe585ddc24e7a

Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.

Workarounds

On 1.12.2 and later, set a finite decoded header list limit, for example http_2_options: [default_local_settings: [max_header_list_size: 65_536]], which resets the stream before the cookie crumbs are joined. From 0.7.0, disabling HTTP/2 with http_2_options: [enabled: false] removes the vulnerable path.