Answer in brief
CVE-2026-105659 records a High severity (CVSS 8.7) vulnerability in HTTP/2 blocked-send deadlines reset on every WINDOW_UPDATE, letting a trickle pin stream processes indefinitely in Bandit. The current sources do not mark it as known exploited. The current feed maps mtrudel/bandit (generic), mtrudel/mtrudel/bandit (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 8.7. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps mtrudel/bandit (generic), mtrudel/mtrudel/bandit (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| mtrudel/banditgeneric | >=1.4.0 <* | * |
| mtrudel/mtrudel/banditgeneric | >=fff06efe3be962b484bd4d3eb339372fda5a231f <d88b21953c65061f21136ea76a89a4f95a2ac7a1 | d88b21953c65061f21136ea76a89a4f95a2ac7a1 |
Published upstream
Oct 14, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Oct 14, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Oct 14, 2026
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.
Quoted source text, attributed separately from HOL analysis.