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

Q: Which deployments are exposed?

Bandit versions from 1.9.0 up to, but not including, 1.14.0 are affected. The issue is reachable through the HTTP/2 handler by an unauthenticated remote client.

Q: What does an attacker need to do to bypass the limits?

The attacker must send a single TCP write containing multiple HTTP/2 frames, with a frame that causes a StreamError partway through the chunk. Earlier HEADERS frames can start streams whose Plug calls continue running even though the handler rolls back its accounting state.

Q: Are configured HTTP/2 connection limits sufficient mitigation?

No. The rollback causes max_concurrent_streams, max_requests, and the rapid-reset limiter to miss streams opened earlier in the affected chunk, so those controls can be bypassed.

Q: How can this manifest operationally?

A client can repeatedly include more HEADERS frames than the configured concurrent-stream limit in each write, causing the excess stream to be refused while earlier streams are forgotten by the accounting. For example, with a limit of 10, five writes can run 50 Plug calls concurrently.

Published Oct 26, 2026

Updated

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.handledata/3 sends RSTSTREAM 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, laststreamid, the rapid-reset timestamps, the HPACK decoder state and the buffer roll back, so maxconcurrentstreams, maxrequests and the rapid-reset limiter never see those streams. A client that sends one HEADERS frame more than maxconcurrentstreams 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 Software

1 affected component

hex/bandit>=1.9.0<1.14.0

Event History

Oct 26, 2026

CVE Published

via MITRE·01:32 PM

Data Sourced

via MITRE·01:32 PM

DescriptionWeakness

Frequently Asked Questions

Which deployments are exposed?

Bandit versions from 1.9.0 up to, but not including, 1.14.0 are affected. The issue is reachable through the HTTP/2 handler by an unauthenticated remote client.

What does an attacker need to do to bypass the limits?

The attacker must send a single TCP write containing multiple HTTP/2 frames, with a frame that causes a StreamError partway through the chunk. Earlier HEADERS frames can start streams whose Plug calls continue running even though the handler rolls back its accounting state.

Are configured HTTP/2 connection limits sufficient mitigation?

No. The rollback causes max_concurrent_streams, max_requests, and the rapid-reset limiter to miss streams opened earlier in the affected chunk, so those controls can be bypassed.

How can this manifest operationally?

A client can repeatedly include more HEADERS frames than the configured concurrent-stream limit in each write, causing the excess stream to be refused while earlier streams are forgotten by the accounting. For example, with a limit of 10, five writes can run 50 Plug calls concurrently.

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

Affected Software

Event History

Frequently Asked Questions

Which deployments are exposed?

What does an attacker need to do to bypass the limits?

Are configured HTTP/2 connection limits sufficient mitigation?

How can this manifest operationally?

Company

Resources

Contact

Frequently Asked Questions

Which deployments are exposed?

What does an attacker need to do to bypass the limits?

Are configured HTTP/2 connection limits sufficient mitigation?

How can this manifest operationally?