CVE-2026-105659
Beschrijving NL
Ongecontroleerde bronconsumptiekwetsbaarheid in mtrudel bandit stelt een niet-geverifieerde externe aanvaller in staat om HTTP/2-streamprocessen voor onbepaalde tijd vast te pinnen via een straaltje kleine WINDOW_update-frames. Een stream waarvan de reactie de verbinding overtreft of stream verzendt vensterblokken totdat de peer meer venster toekent en elk blok een deadline van 15 seconden heeft. Beide deadlines beginnen opnieuw wanneer de peer gedeeltelijke vooruitgang boekt. Bandit.HTTP2.Connection.finish_data/5 zet een gedeeltelijk geavanceerde verzending in de wachtrij in afwachting_verzendt met een nieuwe vervalt_bij, dus elke WINDOW_UPDATE op stream 0 en elk instellingenframe stelt de klok opnieuw in. Bandit.HTTP2.Stream.send_data/3 herhaalt zich op elke stream WINDOW_UPDATE en herbewapent een nieuwe na read_timeout. Een peer die om de paar seconden een paar bytes toekent, houdt het geblokkeerde streamproces, de Plug-status en elke bron die het halverwege de respons vasthoudt levend zolang het blijft druipen, en herhaalt dit over streams en verbindingen om serverprocessen en geheugen uit te putten. De twee paden zijn onafhankelijk. Het blok op streamniveau wordt op zichzelf bereikt door het verbindingsvenster te verbreden met een grote WINDOW_UPDATE op stream 0 en het venster per stream te verkleinen met een kleine SETTINGS_INITIAL_WINDOW_SIZE, dus alleen het pad op verbindingsniveau sluiten laat het exploiteerbaar. Dit probleem treft bandiet: vanaf 1.4.0.
Origineel (Engels) tonen
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 onward.