CVE-2026-74836

This CVE exposes a dangerous asymmetry in HTTP/2 flow control implementation: stream-level send window waits have a 15-second timeout, but the connection-level path that operates on the same shared 65KB window has none. The practical impact is severe: an attacker can send a response payload larger than the connection window, causing the stream to block permanently on connection flow control while its stream-level timer never fires because the process is suspended at the connection layer, not the stream layer. This can be repeated indefinitely across a server's connection pool. What makes this particularly dangerous is that the blocked connection is indistinguishable from a slow client at the transport layer. The socket remains alive, PINGs continue exchanged, memory usage stays flat — there's no anomalous traffic signature to detect. But the pooled upstream connection held by the reverse-proxy Plug remains checked out for the lifetime of the blocked stream, invisible to the pool's normal lifecycle. One pinned Bandit stream can hold one pooled upstream socket hostage indefinitely. The RST_STREAM failure compounds the problem: a stream reset delivered to a process's mailbox cannot be processed while that process is blocked in a synchronous call to another process. This creates a deadlock in the error handling path itself — the normal recovery mechanism is rendered inoperative by the exact condition it should address. You should instrument pending_sends queue depth, synchronous-call wait duration, and correlate Bandit stream states with upstream pool exhaustion. The attack signature is silence — the first observable symptom will likely be upstream service degradation, not anything at the Bandit level. Consider whether the synchronous call pattern itself needs architectural reconsideration rather than merely adding another timeout, since timeouts cannot solve a mailbox that is blocked behind the call that needs to read it.

Reviewed through automated stages and approved by a human before publication.