Vulnerabilities

Vulnerability · CVE-2026-115269

HTTP/2 WINDOW_UPDATE and SETTINGS frames reset the request body read timeout in Bandit

Published Oct 26, 2026 · catalog updated Oct 26, 2026 · HTTP/2 WINDOW_UPDATE and SETTINGS

Last checked Nov 8, 2026. A connected source was read within the last 7 days.

Check if you run it

No confirmed exploitation is on record for CVE-2026-115269. EPSS is 0.60%. Act only if a listed version of HTTP/2 WINDOW_UPDATE and SETTINGS is installed.

Severity

Unknown—

Known exploitation

Not in CISA/VulnCheck KEV

EPSS

0.60%

Remediation

Advisory link

Affected products

Hex bandit

## Summary Allocation of Resources Without Limits or Throttling vulnerability in the HTTP/2 request body reader of mtrudel bandit allows an unauthenticated remote attacker to hold stream processes open indefinitely via WINDOW_UPDATE or empty SETTINGS frames sent while a Plug reads the request body. in waits for each frame with a fresh . A stream WINDOW_UPDATE, or the zero-delta window update that every empty SETTINGS frame delivers to all streams, ends the wait without delivering any body data, and the loop starts a new full countdown. A client that sends one of these 9-byte frames before each countdown expires keeps blocked, together with the stream process and whatever the application holds while reading, for as long as it likes. This issue affects bandit: from 1.4.0 before 1.14.0. ## Details **1. Per-receive timeout.** passes a flat (default 15,000 ms) to , which blocks in 's . **2. Non-progress frames end the wait.** A stream WINDOW_UPDATE, delivered through , or an empty SETTINGS frame, which delivers a zero-delta window update to every stream, is matched inside that . returns a bare , and recurses with the identical , restarting the countdown. **3. Nothing else bounds the read.** The transport read timeout fires only when no bytes arrive, is decremented only by DATA frames, and neither WINDOW_UPDATE nor SETTINGS frames are rate limited. The send path in uses a progress-based deadline; the read path does not. ## Proof of concept 1. Run Bandit with a Plug that calls . 2. Open an HTTP/2 connection and send HEADERS for on stream 1 without END_STREAM. 3. Every 10 seconds, send a WINDOW_UPDATE on stream 1 with an increment of 1. 4. The stream stays open for 120 s, eight times the default 15 s . Without the WINDOW_UPDATE frames, the server ends the read after about 15 s. ## Impact An unauthenticated client can keep a Bandit HTTP/2 stream, and whatever its request handler holds while reading the body, occupied indefinitely for 9 bytes per , and repeat this across many