CVE-2026-74836 in bandit
Zusammenfassung
von VulDB • 22.08.2026
Die Schwachstelle „Allocation of Resources Without Limits or Throttling“ in mtrudel Bandit ermöglicht es einem nicht authentifizierten, entfernten Angreifer, eine unbegrenzte Anzahl von HTTP/2-Stream-Prozessen durch Flow Control auf Verbindungsebene dauerhaft zu blockieren. Wenn der Antwortkörper eines Streams das Sendefenster (Send Window) auf Verbindungsebene von HTTP/2 überläuft (Standardwert: 65.535 Bytes, geteilt zwischen allen Streams auf der Verbindung), wartet Bandit.HTTP2.Connection die restlichen Bytes und einen Reply-Closure in pending_sends ab, und der Stream-Prozess blockiert für immer innerhalb eines synchronen Aufrufs an den Verbindungsprozess. Es gibt keine Begrenzung für diese Wartezeit, und es wird nichts aus der Warteschlange entfernt: Ein RST_STREAM des Clients für den blockierten Stream wird zwar in dessen Postfach zugestellt, aber während er im Aufruf feststeckt, nie gelesen; daher bewirkt das Abbrechen (Cancel) keine Freigabe, und periodische PING-Frames verhindern, dass der Lese-Timeout auf Transportebene jemals auslöst. Die entsprechende Blockade des Sendefensters auf Stream-Ebene ist bereits mit 15 Sekunden begrenzt; der Pfad auf Verbindungsebene hatte eine solche Begrenzung nicht.
Jeder gestoppte Stream bindet seinen Prozess, den Plug-Zustand und alle Ressourcen, die der Plug während des blockierten Schreibvorgangs hält (z. B. eine gepoolte Upstream-Verbindung in einem Reverse-Proxy-Pug), fest. Der Angreifer wählt einen beliebigen Endpunkt aus, dessen Antwort das Verbindungsfenster überschreitet (häufig bei den meisten nicht-trivialen Payloads), gewährt ein großzügiges Stream-Fenster, sodass nur das Verbindungsfenster es begrenzt, und hält die Verbindung mit periodischen PINGs am Leben; das Primitive ist über Streams und Verbindungen hinweg wiederholbar, wobei pro Instanz jeweils eine leere Socket-Verbindung benötigt wird.
Dieses Problem betrifft bandit: von Version 0.3.4 bis vor 1.12.5.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.