Allocation of Resources Without Limits or Throttling vulnerability in the HTTP/1.1 chunked body reader of mtrudel bandit allows an unauthenticated remote attacker to exhaust server memory and CPU via a request body made of many 1-byte chunks.
\nThe chunked reader in lib/bandit/http1/socket.ex keeps every chunk as its own list cell and binary term until IO.iodata_to_binary/1 joins them, and nothing limits the number of chunks. The :length option of read_body/2 counts only data bytes, so tiny chunks cost far more memory than their payload: 48 MB of 1-byte chunks grew one handler process to about 500 MB and took about 6 s of CPU. The route does not need to read the body, because on keep-alive connections ensure_completed/1 drains unread bodies through the same reader.
This issue affects bandit: from 0.1.0 before 1.14.0.
"},{"base64":false,"type":"text/markdown","value":"Allocation of Resources Without Limits or Throttling vulnerability in the HTTP/1.1 chunked body reader of mtrudel bandit allows an unauthenticated remote attacker to exhaust server memory and CPU via a request body made of many 1-byte chunks.\n\nThe chunked reader in `lib/bandit/http1/socket.ex` keeps every chunk as its own list cell and binary term until `IO.iodata_to_binary/1` joins them, and nothing limits the number of chunks. The `:length` option of `read_body/2` counts only data bytes, so tiny chunks cost far more memory than their payload: 48 MB of 1-byte chunks grew one handler process to about 500 MB and took about 6 s of CPU. The route does not need to read the body, because on keep-alive connections `ensure_completed/1` drains unread bodies through the same reader.\n\nThis issue affects bandit: from 0.1.0 before 1.14.0."}],"value":"Allocation of Resources Without Limits or Throttling vulnerability in the HTTP/1.1 chunked body reader of mtrudel bandit allows an unauthenticated remote attacker to exhaust server memory and CPU via a request body made of many 1-byte chunks.\n\nThe chunked reader in lib/bandit/http1/socket.ex keeps every chunk as its own list cell and binary term until IO.iodata_to_binary/1 joins them, and nothing limits the number of chunks. The :length option of read_body/2 counts only data bytes, so tiny chunks cost far more memory than their payload: 48 MB of 1-byte chunks grew one handler process to about 500 MB and took about 6 s of CPU. The route does not need to read the body, because on keep-alive connections ensure_completed/1 drains unread bodies through the same reader.\n\nThis issue affects bandit: from 0.1.0 before 1.14.0."}],"impacts":[{"capecId":"CAPEC-130","descriptions":[{"lang":"en","supportingMedia":[{"base64":false,"type":"text/html","value":"An unauthenticated client can make a single HTTP/1.1 request hold many times its body size in server memory (about 48 MB for a 1 MB body in the reporter's test), and keep CPU busy while the chunks are joined. This affects any Bandit server that accepts HTTP/1.1 requests, whether or not its routes read the body.
"},{"base64":false,"type":"text/markdown","value":"An unauthenticated client can make a single HTTP/1.1 request hold many times its body size in server memory (about 48 MB for a 1 MB body in the reporter's test), and keep CPU busy while the chunks are joined. This affects any Bandit server that accepts HTTP/1.1 requests, whether or not its routes read the body."}],"value":"An unauthenticated client can make a single HTTP/1.1 request hold many times its body size in server memory (about 48 MB for a 1 MB body in the reporter's test), and keep CPU busy while the chunks are joined. This affects any Bandit server that accepts HTTP/1.1 requests, whether or not its routes read the body."}]}],"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:31:48.184Z","orgId":"6b3ad84c-e1a6-4bf7-a703-f496b71e49db","shortName":"EEF"},"references":[{"name":"HTTP/1.1 chunked request bodies made of 1-byte chunks amplify memory use in Bandit","tags":["vendor-advisory","related"],"url":"https://github.com/mtrudel/bandit/security/advisories/GHSA-jwh3-j29h-qfmw"},{"name":"EEF CNA record for CVE-2026-111101","tags":["related"],"url":"https://cna.erlef.org/cves/CVE-2026-111101.html"},{"name":"OSV record EEF-CVE-2026-111101","tags":["related"],"url":"https://osv.dev/vulnerability/EEF-CVE-2026-111101"},{"name":"Introducing commit 7201270 in mtrudel/bandit","tags":["related"],"url":"https://github.com/mtrudel/bandit/commit/7201270c34b90f6c9e15c0386c2bb802c0c72ab4"},{"name":"Fix commit 220b9df in mtrudel/bandit","tags":["patch"],"url":"https://github.com/mtrudel/bandit/commit/220b9dfd27f9a21305be2afc75cbe585ddc24e7a"}],"source":{"discovery":"UNKNOWN"},"title":"HTTP/1.1 chunked request bodies made of 1-byte chunks amplify memory use in Bandit","workarounds":[{"lang":"en","supportingMedia":[{"base64":false,"type":"text/html","value":"From 0.7.0, a server whose clients and proxies all speak HTTP/2 can disable HTTP/1 with http_1_options: [enabled: false], so that the vulnerable chunked body reader never runs.
Plug.Conn.read_body(conn, length: 1_000_000, read_length: 1_000_000).POST / with Transfer-Encoding: chunked and a body of 1,000,000 chunks of 1\\r\\nA\\r\\n, followed by 0\\r\\n\\r\\n.read_body returns the 1,000,000 body bytes, the handler process holds about 48 MB and BEAM memory has grown by about 55 MB, for 6 MB sent.1. Per-chunk accumulation. do_read_chunked_data! in lib/bandit/http1/socket.ex collects chunks as [body | chunk], adding a cons cell and a binary term for every chunk.
2. Byte-only limit. :length limits data bytes, not the number of chunks, so a body of 1\\r\\nx\\r\\n chunks becomes an 8-million-element improper list before IO.iodata_to_binary runs. Sending 48 MB of 1-byte chunks grew the handler heap to about 500 MB and used about 6 s of CPU. The same body as one 8 MB chunk peaked at about 16 MB and took 5 ms.
3. No body read needed. On keep-alive connections, ensure_completed/1 drains unread bodies through the same path. Against a Plug that never calls read_body, the attack used about 417 MB.