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.
\nWhen 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.
"},{"base64":false,"type":"text/markdown","value":"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.\n\nWhen 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.\n\nThis issue affects bandit: from 1.9.0 before 1.14.0."}],"value":"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.\n\nWhen 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.\n\nThis issue affects bandit: from 1.9.0 before 1.14.0."}],"impacts":[{"capecId":"CAPEC-130","descriptions":[{"lang":"en","supportingMedia":[{"base64":false,"type":"text/html","value":"An unauthenticated client can run more concurrent Plug calls on one HTTP/2 connection than the configured max_concurrent_streams allows (five times the limit in the reporter's test), tying up the server processes, CPU and memory the limit is meant to cap. Servers that serve HTTP/2 with a finite max_concurrent_streams are affected.
Disable HTTP/2 with http_2_options: [enabled: false], so that the vulnerable HTTP/2 handler never runs.
http_2_options: [default_local_settings: [max_concurrent_streams: 10]].1. Function-level rescue. Bandit.HTTP2.Handler.handle_data/3 in lib/bandit/http2/handler.ex deserializes every frame in a TCP chunk inside an Enum.reduce_while/3 and wraps the whole function in a rescue. Inside that rescue, state is the original function argument, not the reduce_while accumulator.
2. Rollback on StreamError. When Bandit.HTTP2.Connection.handle_frame/3 raises StreamError partway through the chunk, rescue_stream_error/3 sends RST_STREAM and returns {:continue, state} with the connection as it was before the chunk. The rest of the chunk is dropped.
3. Lost bookkeeping. Frames already handled keep their side effects: their stream processes are running the Plug. But the stream counts, last_stream_id, reset_stream_timestamps, recv_hpack_state and buffer are rolled back, so max_concurrent_streams, max_requests and the rapid-reset limiter no longer count those streams. The same rollback drops HPACK table updates, which can mix up headers between requests, misaligns frame parsing, and sends a stale last_stream_id in GOAWAY.