HTTP/1 chunked body reader ignores length cap in bandit
Allocation of Resources Without Limits or Throttling vulnerability in mtrudel bandit allows unauthenticated remote denial of service via memory exhaustion. The chunked clause of 'Elixir.Bandit.HTTP1.Socket':read_data/2 in lib/bandit/http1/socket.ex ignores the caller-supplied :length option when reading HTTP/1 chunked request bodies. Instead of capping the accumulated body at the configured limit (e.g. Plug.Parsers' default 8 MB), do_read_chunked_data!/5 buffers every received chunk into an iolist unconditionally and materializes the entire body as a single binary. The function always returns {:ok, body, ...}, so callers cannot interpose a 413 response. Because Plug.Parsers runs before routing and authentication in the standard Phoenix endpoint, an unauthenticated attacker needs no valid route or credentials. Sending a single Transfer-Encoding: chunked POST request with an arbitrarily large body to any path causes the BEAM process to exhaust available memory and be terminated by the OS OOM killer. The content-length path in the same function correctly enforces the limit and is not affected. This issue affects bandit: from 1.4.0 before 1.11.1.
- Products
- Not specified
- Affected versions
- Not specified
- Fixed versions
- Not specified
- CVEs
- CVE-2026-39803
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 3 Nov 2026, 03:52 UTC · Revision 1
Source evidence
HTTP/1 chunked body reader ignores length cap in bandit
core-osv · Original sourcePublished 13 May 2026, 13:36 UTC
Allocation of Resources Without Limits or Throttling vulnerability in mtrudel bandit allows unauthenticated remote denial of service via memory exhaustion. The chunked clause of 'Elixir.Bandit.HTTP1.Socket':read_data/2 in lib/bandit/http1/socket.ex ignores the caller-supplied :length option when reading HTTP/1 chunked request bodies. Instead of capping the accumulated body at the configured limit (e.g. Plug.Parsers' default 8 MB), do_read_chunked_data!/5 buffers every received chunk into an iolist unconditionally and materializes the entire body as a single binary. The function always returns {:ok, body, ...}, so callers cannot interpose a 413 response. Because Plug.Parsers runs before routing and authentication in the standard Phoenix endpoint, an unauthenticated attacker needs no valid route or credentials. Sending a single Transfer-Encoding: chunked POST request with an arbitrarily large body to any path causes the BEAM process to exhaust available memory and be terminated by the OS OOM killer. The content-length path in the same function correctly enforces the limit and is not affected. This issue affects bandit: from 1.4.0 before 1.11.1.
osv:CVE-2026-39803
Complete source record
{
"id": "18d703ed7c5b2404d2302788b2679caaaa5ef74317946ee9c90797f225ca02ee",
"url": "https://osv.dev/vulnerability/CVE-2026-39803",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "HTTP/1 chunked body reader ignores length cap in bandit",
"summary": "Allocation of Resources Without Limits or Throttling vulnerability in mtrudel bandit allows unauthenticated remote denial of service via memory exhaustion. The chunked clause of 'Elixir.Bandit.HTTP1.Socket':read_data/2 in lib/bandit/http1/socket.ex ignores the caller-supplied :length option when reading HTTP/1 chunked request bodies. Instead of capping the accumulated body at the configured limit (e.g. Plug.Parsers' default 8 MB), do_read_chunked_data!/5 buffers every received chunk into an iolist unconditionally and materializes the entire body as a single binary. The function always returns {:ok, body, ...}, so callers cannot interpose a 413 response. Because Plug.Parsers runs before routing and authentication in the standard Phoenix endpoint, an unauthenticated attacker needs no valid route or credentials. Sending a single Transfer-Encoding: chunked POST request with an arbitrarily large body to any path causes the BEAM process to exhaust available memory and be terminated by the OS OOM killer. The content-length path in the same function correctly enforces the limit and is not affected. This issue affects bandit: from 1.4.0 before 1.11.1.",
"evidence": "osv:CVE-2026-39803",
"products": [],
"severity": "high",
"structured": {
"id": "CVE-2026-39803",
"aliases": [
"CVE-2026-39803",
"EEF-CVE-2026-39803",
"GHSA-9q9q-324x-93r2"
],
"metrics": [
{
"type": "CVSS_V4",
"score": "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"
}
],
"affected": [
{
"ranges": [
{
"repo": "https://github.com/mtrudel/bandit",
"type": "GIT",
"events": [
{
"introduced": "e5d4262b07b3e1026c57647b281dccfababea13b"
},
{
"fixed": "40a1b8fc924694a0125bbaa7fee101fa43feeb52"
},
{
"fixed": "ae3520dfdbfab115c638f8c7f6f6b805db34e1ab"
}
],
"database_specific": {
"extracted_events": [
{
"cpe": "cpe:2.3:a:mtrudel:bandit:*:*:*:*:*:*:*:*",
"range": [
{
"introduced": "1.4.0"
},
{
"fixed": "1.11.1"
}
],
"source": "CPE_RANGE"
},
{
"range": [
{
"fixed": "ae3520dfdbfab115c638f8c7f6f6b805db34e1ab"
}
],
"source": "REFERENCES_COMMIT"
}
]
}
}
],
"versions": [
"1.11.0",
"1.10.4",
"1.10.3",
"1.10.2",
"1.10.1",
"1.10.0",
"1.9.0",
"1.8.0",
"1.7.0",
"1.6.11",
"1.6.10",
"1.6.9",
"1.6.8",
"1.6.7",
"1.6.6",
"1.6.5",
"1.6.4",
"1.6.3",
"1.6.2",
"1.6.1",
"1.6.0",
"1.5.7",
"1.5.6",
"1.5.5",
"1.5.4",
"1.5.3",
"1.5.2",
"1.5.1",
"1.5.0",
"1.4.2",
"1.4.1",
"1.4.0"
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-39803.json"
}
}
],
"modified": "2026-10-28T02:30:26.083700853Z",
"provider": "osv",
"references": [
"https://cna.erlef.org/cves/CVE-2026-39803.html",
"https://github.com",
"https://osv.dev/vulnerability/EEF-CVE-2026-39803",
"https://repo.hex.pm",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/39xxx/CVE-2026-39803.json",
"https://github.com/mtrudel/bandit/security/advisories/GHSA-9q9q-324x-93r2",
"https://nvd.nist.gov/vuln/detail/CVE-2026-39803",
"https://github.com/mtrudel/bandit/commit/ae3520dfdbfab115c638f8c7f6f6b805db34e1ab",
"https://github.com/mtrudel/bandit"
],
"provider_metadata": {
"cwe_ids": [
"CWE-770"
],
"cna_assigner": "EEF",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/39xxx/CVE-2026-39803.json"
}
},
"related_cves": [
{
"value": "CVE-2026-39803",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": "/severity/0/score"
},
"source_id": "core-osv",
"document_id": 492287,
"published_at": "2026-05-13T13:36:09.648+00:00"
}