{ "dataType": "CVE_RECORD", "dataVersion": "5.2", "cveMetadata": { "cveId": "CVE-2026-115269", "assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db", "state": "PUBLISHED", "assignerShortName": "EEF", "dateReserved": "2026-10-23T10:15:01.872Z", "datePublished": "2026-10-26T13:30:24.621Z", "dateUpdated": "2026-10-26T13:30:24.621Z" }, "containers": { "cna": { "affected": [ { "collectionURL": "https://repo.hex.pm", "cpes": [ "cpe:2.3:a:mtrudel:bandit:*:*:*:*:*:*:*:*" ], "defaultStatus": "unaffected", "packageName": "bandit", "packageURL": "pkg:hex/bandit", "product": "bandit", "repo": "https://github.com/mtrudel/bandit", "vendor": "mtrudel", "versions": [ { "lessThan": "1.14.0", "status": "affected", "version": "1.4.0", "versionType": "semver" } ] }, { "collectionURL": "https://github.com", "cpes": [ "cpe:2.3:a:mtrudel:bandit:*:*:*:*:*:*:*:*" ], "defaultStatus": "unaffected", "packageName": "mtrudel/bandit", "packageURL": "pkg:github/mtrudel/bandit", "product": "bandit", "repo": "https://github.com/mtrudel/bandit", "vendor": "mtrudel", "versions": [ { "lessThan": "220b9dfd27f9a21305be2afc75cbe585ddc24e7a", "status": "affected", "version": "fff06efe3be962b484bd4d3eb339372fda5a231f", "versionType": "git" } ] } ], "cpeApplicability": [ { "nodes": [ { "cpeMatch": [ { "criteria": "cpe:2.3:a:mtrudel:bandit:*:*:*:*:*:*:*:*", "versionEndExcluding": "1.14.0", "versionStartIncluding": "1.4.0", "vulnerable": true } ], "negate": false, "operator": "OR" } ], "operator": "AND" } ], "credits": [ { "lang": "en", "type": "analyst", "value": "Peter Ullrich" }, { "lang": "en", "type": "reporter", "value": "Daniel Coles" }, { "lang": "en", "type": "remediation developer", "value": "Mat Trudel" }, { "lang": "en", "type": "analyst", "value": "Jonatan Männchen / EEF" } ], "dateAssigned": "2026-10-23T13:25:29.000Z", "descriptions": [ { "lang": "en", "supportingMedia": [ { "base64": false, "type": "text/html", "value": "

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.

\n

Bandit.HTTP2.Stream.do_read_data/4 in lib/bandit/http2/stream.ex waits for each frame with a fresh read_timeout. 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 read_body blocked, together with the stream process and whatever the application holds while reading, for as long as it likes.

\n

This issue affects bandit: from 1.4.0 before 1.14.0.

" }, { "base64": false, "type": "text/markdown", "value": "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.\n\n`Bandit.HTTP2.Stream.do_read_data/4` in `lib/bandit/http2/stream.ex` waits for each frame with a fresh `read_timeout`. 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 `read_body` blocked, together with the stream process and whatever the application holds while reading, for as long as it likes.\n\nThis issue affects bandit: from 1.4.0 before 1.14.0." } ], "value": "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.\n\nBandit.HTTP2.Stream.do_read_data/4 in lib/bandit/http2/stream.ex waits for each frame with a fresh read_timeout. 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 read_body blocked, together with the stream process and whatever the application holds while reading, for as long as it likes.\n\nThis issue affects bandit: from 1.4.0 before 1.14.0." } ], "impacts": [ { "capecId": "CAPEC-469", "descriptions": [ { "lang": "en", "supportingMedia": [ { "base64": false, "type": "text/html", "value": "

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 read_timeout, and repeat this across many streams and connections. This affects any Bandit server with HTTP/2 enabled whose routes read request bodies, which Plug.Parsers does for POST, PUT and PATCH.

" }, { "base64": false, "type": "text/markdown", "value": "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 `read_timeout`, and repeat this across many streams and connections. This affects any Bandit server with HTTP/2 enabled whose routes read request bodies, which `Plug.Parsers` does for POST, PUT and PATCH." } ], "value": "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 read_timeout, and repeat this across many streams and connections. This affects any Bandit server with HTTP/2 enabled whose routes read request bodies, which Plug.Parsers does for POST, PUT and PATCH." } ] } ], "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-835", "description": "CWE-835 Loop with Unreachable Exit Condition ('Infinite Loop')", "lang": "en", "type": "CWE" } ] }, { "descriptions": [ { "cweId": "CWE-770", "description": "CWE-770 Allocation of Resources Without Limits or Throttling", "lang": "en", "type": "CWE" } ] } ], "providerMetadata": { "orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db", "shortName": "EEF", "dateUpdated": "2026-10-26T13:30:24.621Z" }, "references": [ { "name": "HTTP/2 WINDOW_UPDATE and SETTINGS frames reset the request body read timeout in Bandit", "tags": [ "vendor-advisory", "related" ], "url": "https://github.com/mtrudel/bandit/security/advisories/GHSA-p2qv-vx88-385x" }, { "name": "EEF CNA record for CVE-2026-115269", "tags": [ "related" ], "url": "https://cna.erlef.org/cves/CVE-2026-115269.html" }, { "name": "OSV record EEF-CVE-2026-115269", "tags": [ "related" ], "url": "https://osv.dev/vulnerability/EEF-CVE-2026-115269" }, { "name": "Introducing commit fff06ef in mtrudel/bandit", "tags": [ "related" ], "url": "https://github.com/mtrudel/bandit/commit/fff06efe3be962b484bd4d3eb339372fda5a231f" }, { "name": "Fix commit 220b9df in mtrudel/bandit", "tags": [ "patch" ], "url": "https://github.com/mtrudel/bandit/commit/220b9dfd27f9a21305be2afc75cbe585ddc24e7a" } ], "source": { "discovery": "UNKNOWN" }, "title": "HTTP/2 WINDOW_UPDATE and SETTINGS frames reset the request body read timeout in Bandit", "workarounds": [ { "lang": "en", "supportingMedia": [ { "base64": false, "type": "text/html", "value": "

Disable HTTP/2 with http_2_options: [enabled: false], so that the vulnerable read path never runs.

" }, { "base64": false, "type": "text/markdown", "value": "Disable HTTP/2 with `http_2_options: [enabled: false]`, so that the vulnerable read path never runs." } ], "value": "Disable HTTP/2 with http_2_options: [enabled: false], so that the vulnerable read path never runs." } ], "x_proofOfConcept": [ { "lang": "en", "supportingMedia": [ { "base64": false, "type": "text/html", "value": "
    \n
  1. Run Bandit with a Plug that calls Plug.Conn.read_body/2.
    2. \n
  2. Open an HTTP/2 connection and send HEADERS for POST / on stream 1 without END_STREAM.
    3. \n
  3. Every 10 seconds, send a WINDOW_UPDATE on stream 1 with an increment of 1.
    4. \n
  4. The stream stays open for 120 s, eight times the default 15 s read_timeout. Without the WINDOW_UPDATE frames, the server ends the read after about 15 s.
    5. \n
" }, { "base64": false, "type": "text/markdown", "value": "1. Run Bandit with a Plug that calls `Plug.Conn.read_body/2`.\n2. Open an HTTP/2 connection and send HEADERS for `POST /` on stream 1 without END_STREAM.\n3. Every 10 seconds, send a WINDOW_UPDATE on stream 1 with an increment of 1.\n4. The stream stays open for 120 s, eight times the default 15 s `read_timeout`. Without the WINDOW_UPDATE frames, the server ends the read after about 15 s." } ], "value": "* Run Bandit with a Plug that calls Plug.Conn.read_body/2.\n* Open an HTTP/2 connection and send HEADERS for POST / on stream 1 without END_STREAM.\n* Every 10 seconds, send a WINDOW_UPDATE on stream 1 with an increment of 1.\n* The stream stays open for 120 s, eight times the default 15 s read_timeout. Without the WINDOW_UPDATE frames, the server ends the read after about 15 s." } ], "x_technicalAnalysis": [ { "lang": "en", "supportingMedia": [ { "base64": false, "type": "text/html", "value": "

1. Per-receive timeout. Bandit.HTTP2.Stream.read_data/2 passes a flat read_timeout (default 15,000 ms) to do_read_data/4, which blocks in do_recv/2's receive ... after timeout.

\n

2. Non-progress frames end the wait. A stream WINDOW_UPDATE, delivered through Bandit.HTTP2.Connection.handle_frame/3, or an empty SETTINGS frame, which delivers a zero-delta window update to every stream, is matched inside that receive. do_recv_send_window_update/2 returns a bare %Stream{}, and do_read_data/4 recurses with the identical timeout, restarting the countdown.

\n

3. Nothing else bounds the read. The transport read timeout fires only when no bytes arrive, max_bytes is decremented only by DATA frames, and neither WINDOW_UPDATE nor SETTINGS frames are rate limited. The send path in do_send_data/4 uses a progress-based deadline; the read path does not.

" }, { "base64": false, "type": "text/markdown", "value": "**1. Per-receive timeout.** `Bandit.HTTP2.Stream.read_data/2` passes a flat `read_timeout` (default 15,000 ms) to `do_read_data/4`, which blocks in `do_recv/2`'s `receive ... after timeout`.\n\n**2. Non-progress frames end the wait.** A stream WINDOW_UPDATE, delivered through `Bandit.HTTP2.Connection.handle_frame/3`, or an empty SETTINGS frame, which delivers a zero-delta window update to every stream, is matched inside that `receive`. `do_recv_send_window_update/2` returns a bare `%Stream{}`, and `do_read_data/4` recurses with the identical `timeout`, restarting the countdown.\n\n**3. Nothing else bounds the read.** The transport read timeout fires only when no bytes arrive, `max_bytes` is decremented only by DATA frames, and neither WINDOW_UPDATE nor SETTINGS frames are rate limited. The send path in `do_send_data/4` uses a progress-based deadline; the read path does not." } ], "value": "1. Per-receive timeout. Bandit.HTTP2.Stream.read_data/2 passes a flat read_timeout (default 15,000 ms) to do_read_data/4, which blocks in do_recv/2's receive ... after timeout.\n\n2. Non-progress frames end the wait. A stream WINDOW_UPDATE, delivered through Bandit.HTTP2.Connection.handle_frame/3, or an empty SETTINGS frame, which delivers a zero-delta window update to every stream, is matched inside that receive. do_recv_send_window_update/2 returns a bare %Stream{}, and do_read_data/4 recurses with the identical timeout, restarting the countdown.\n\n3. Nothing else bounds the read. The transport read timeout fires only when no bytes arrive, max_bytes is decremented only by DATA frames, and neither WINDOW_UPDATE nor SETTINGS frames are rate limited. The send path in do_send_data/4 uses a progress-based deadline; the read path does not." } ] } } }