Allocation of Resources Without Limits or Throttling vulnerability in the HTTP/2 implementation of mtrudel bandit allows an unauthenticated remote attacker to exhaust server memory via DATA frames sent past the advertised receive window. The attacker requests a response larger than the 65,535-byte initial window and withholds WINDOW_UPDATE, so the stream process blocks while sending and stops reading, then floods small DATA frames on that stream. Every frame is queued in the stream's mailbox until the BEAM node runs out of memory.
Bandit.HTTP2.Connection.handle_frame/3 in lib/bandit/http2/connection.ex forwards each DATA frame to the stream process without consulting the receive window, and Bandit.HTTP2.FlowControl.compute_recv_window/2 replenishes the window as data arrives rather than as it is consumed, and never answers a violation with FLOW_CONTROL_ERROR.
This issue affects bandit: from 0.3.1 before 1.14.0.
"},{"base64":false,"type":"text/markdown","value":"Allocation of Resources Without Limits or Throttling vulnerability in the HTTP/2 implementation of mtrudel bandit allows an unauthenticated remote attacker to exhaust server memory via DATA frames sent past the advertised receive window. The attacker requests a response larger than the 65,535-byte initial window and withholds `WINDOW_UPDATE`, so the stream process blocks while sending and stops reading, then floods small DATA frames on that stream. Every frame is queued in the stream's mailbox until the BEAM node runs out of memory.\n\n`Bandit.HTTP2.Connection.handle_frame/3` in `lib/bandit/http2/connection.ex` forwards each DATA frame to the stream process without consulting the receive window, and `Bandit.HTTP2.FlowControl.compute_recv_window/2` replenishes the window as data arrives rather than as it is consumed, and never answers a violation with `FLOW_CONTROL_ERROR`.\n\nThis issue affects bandit: from 0.3.1 before 1.14.0."}],"value":"Allocation of Resources Without Limits or Throttling vulnerability in the HTTP/2 implementation of mtrudel bandit allows an unauthenticated remote attacker to exhaust server memory via DATA frames sent past the advertised receive window. The attacker requests a response larger than the 65,535-byte initial window and withholds WINDOW_UPDATE, so the stream process blocks while sending and stops reading, then floods small DATA frames on that stream. Every frame is queued in the stream's mailbox until the BEAM node runs out of memory.\n\nBandit.HTTP2.Connection.handle_frame/3 in lib/bandit/http2/connection.ex forwards each DATA frame to the stream process without consulting the receive window, and Bandit.HTTP2.FlowControl.compute_recv_window/2 replenishes the window as data arrives rather than as it is consumed, and never answers a violation with FLOW_CONTROL_ERROR.\n\nThis issue affects bandit: from 0.3.1 before 1.14.0."}],"impacts":[{"capecId":"CAPEC-125","descriptions":[{"lang":"en","supportingMedia":[{"base64":false,"type":"text/html","value":"An unauthenticated remote client can exhaust the memory of any Bandit server with HTTP/2 enabled by flooding DATA frames on a stream that is not reading its request body, such as one stalled sending a large response. The queued frames live in the BEAM node's memory, so exhausting it takes down every application on the node, not just the HTTP listener.
"},{"base64":false,"type":"text/markdown","value":"An unauthenticated remote client can exhaust the memory of any Bandit server with HTTP/2 enabled by flooding DATA frames on a stream that is not reading its request body, such as one stalled sending a large response. The queued frames live in the BEAM node's memory, so exhausting it takes down every application on the node, not just the HTTP listener."}],"value":"An unauthenticated remote client can exhaust the memory of any Bandit server with HTTP/2 enabled by flooding DATA frames on a stream that is not reading its request body, such as one stalled sending a large response. The queued frames live in the BEAM node's memory, so exhausting it takes down every application on the node, not just the HTTP listener."}]}],"metrics":[{"cvssV4_0":{"Automatable":"NOT_DEFINED","Recovery":"NOT_DEFINED","Safety":"NOT_DEFINED","attackComplexity":"LOW","attackRequirements":"NONE","attackVector":"NETWORK","baseScore":8.7,"baseSeverity":"HIGH","privilegesRequired":"NONE","providerUrgency":"NOT_DEFINED","subAvailabilityImpact":"NONE","subConfidentialityImpact":"NONE","subIntegrityImpact":"NONE","userInteraction":"NONE","valueDensity":"NOT_DEFINED","vectorString":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","version":"4.0","vulnAvailabilityImpact":"HIGH","vulnConfidentialityImpact":"NONE","vulnIntegrityImpact":"NONE","vulnerabilityResponseEffort":"NOT_DEFINED"},"format":"CVSS","scenarios":[{"lang":"en","value":"GENERAL"}]}],"problemTypes":[{"descriptions":[{"cweId":"CWE-770","description":"CWE-770 Allocation of Resources Without Limits or Throttling","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-10-26T13:29:42.520Z","orgId":"6b3ad84c-e1a6-4bf7-a703-f496b71e49db","shortName":"EEF"},"references":[{"name":"HTTP/2 inbound flow control is not enforced, letting a client queue unbounded DATA in stream processes in Bandit","tags":["vendor-advisory","related"],"url":"https://github.com/mtrudel/bandit/security/advisories/GHSA-c3g7-2pg5-qvwh"},{"name":"EEF CNA record for CVE-2026-108525","tags":["related"],"url":"https://cna.erlef.org/cves/CVE-2026-108525.html"},{"name":"OSV record EEF-CVE-2026-108525","tags":["related"],"url":"https://osv.dev/vulnerability/EEF-CVE-2026-108525"},{"name":"Introducing commit c8dc1e9 in mtrudel/bandit","tags":["related"],"url":"https://github.com/mtrudel/bandit/commit/c8dc1e97050cf359f61ed6cdd110f3cdaf1d6f5f"},{"name":"Fix commit 220b9df in mtrudel/bandit","tags":["patch"],"url":"https://github.com/mtrudel/bandit/commit/220b9dfd27f9a21305be2afc75cbe585ddc24e7a"}],"source":{"discovery":"UNKNOWN"},"title":"HTTP/2 inbound flow control is not enforced, letting a client queue unbounded DATA in stream processes in Bandit","workarounds":[{"lang":"en","supportingMedia":[{"base64":false,"type":"text/html","value":"From 0.7.0, disable HTTP/2 with http_2_options: [enabled: false], which removes the vulnerable path.
WINDOW_UPDATE. The server sends one window's worth and the stream blocks in send_data/3.WINDOW_UPDATE with an increment of 1 to keep the blocked send alive.FLOW_CONTROL_ERROR nor GOAWAY while its memory grows with every frame.1. Connection-level window (lib/bandit/http2/connection.ex, lib/bandit/http2/flow_control.ex)
The handle_frame/3 clause for DATA frames sends the payload to the stream process before any window is checked. It then calls compute_recv_window/2, which subtracts the frame size and, once the window drops below 2^30, advertises a WINDOW_UPDATE back up to 2^31-1. A negative window is accepted, so a peer that overruns the window is never refused, and the window refills when data arrives rather than when it is consumed.
2. Stream-level window (lib/bandit/http2/stream.ex)
The stream receive window is debited only when the stream process reads the DATA message, and it never rejects a violation either.
\n3. Accumulation
\nWhile send_data/3 waits for send window, its selective receive matches only window updates and resets, so DATA messages pile up unread in the mailbox. A stream WINDOW_UPDATE of 1 byte, sent at intervals under the 15-second send timeout, keeps the stream alive while the attacker floods 1-byte DATA frames.