Uncontrolled Resource Consumption vulnerability in mtrudel bandit allows an unauthenticated remote…

Why it is Amber

• CVSS 8.7 high
• Remotely exploitable without logging in

References

• https://cna.erlef.org/cves/CVE-2026-105659.html
• https://github.com/mtrudel/bandit/commit/d88b21953c65061f21136ea76a89a4f95a2ac7a1
• https://github.com/mtrudel/bandit/commit/fff06efe3be962b484bd4d3eb339372fda5a231f
• https://github.com/mtrudel/bandit/security/advisories/GHSA-69m6-wcv4-rwcf
• https://osv.dev/vulnerability/EEF-CVE-2026-105659
• https://github.com/mtrudel/bandit/security/advisories/GHSA-69m6-wcv4-rwcf

Original description

Uncontrolled Resource Consumption vulnerability in mtrudel bandit allows an unauthenticated remote attacker to pin HTTP/2 stream processes indefinitely via a trickle of small WINDOW_UPDATE frames. A stream whose response outruns the connection or stream send window blocks until the peer grants more window, and each block carries a 15 second deadline. Both deadlines restart whenever the peer makes partial progress. Bandit.HTTP2.Connection.finish_data/5 re-queues a partially advanced send in pending_sends with a fresh expires_at, so every WINDOW_UPDATE on stream 0, and every SETTINGS frame, resets the clock. Bandit.HTTP2.Stream.send_data/3 recurses on each stream WINDOW_UPDATE and re-arms a fresh after read_timeout. A peer that grants a few bytes every few seconds keeps the blocked stream process, its Plug state and any resource it holds mid-response alive for as long as it keeps dripping, and repeats this across streams and connections to exhaust server processes and memory. The two paths are independent. The stream-level block is reached on its own by widening the connection window with a large WINDOW_UPDATE on stream 0 and shrinking the per-stream window with a small SETTINGS_INITIAL_WINDOW_SIZE, so closing only the connection-level path leaves it exploitable. This issue affects bandit: from 1.4.0 before 1.13.0.