HTTP/2 StreamError recovery rolls back connection state and bypasses per-connection limits in Bandit

Overview

Improper Cleanup on Thrown Exception vulnerability in the HTTP/2 handler of mtrudel bandit allows an unauthenticated remote attacker to bypass per-connection resource limits via a single TCP write that carries several frames, one of which raises a stream error.

When a frame raises StreamError partway through a chunk, Bandit.HTTP2.Handler.handle_data/3 sends RST_STREAM and continues with the connection state from before the chunk, dropping the rest of it. Streams opened by earlier frames in the chunk keep running their Plug calls, but the stream counts, last_stream_id, the rapid-reset timestamps, the HPACK decoder state and the buffer roll back, so max_concurrent_streams, max_requests and the rapid-reset limiter never see those streams. A client that sends one HEADERS frame more than max_concurrent_streams in each write has the extra refused and the others forgotten: with a limit of 10, five such writes run 50 Plug calls at once.

This issue affects bandit: from 1.9.0 before 1.14.0.

Affected

• bandit >= 1.9.0 < 1.14.0
• mtrudel/bandit >= 3ad49c80c268891e7cc412e69649115456638e59 < 220b9dfd27f9a21305be2afc75cbe585ddc24e7a

Remediation

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

Workarounds

Disable HTTP/2 with http_2_options: [enabled: false], so that the vulnerable HTTP/2 handler never runs.