{"id":"CVE-2026-47077","aliases":["EEF-CVE-2026-47077","GHSA-jq4m-q6p2-8gwc"],"url":"https://o3.security/vulnerability/CVE-2026-47077","summary":"Unbounded body accumulation in HTTP/3 response loop in hackney","details":"### Summary\n\n`hackney_h3:await_response_loop/6` in `src/hackney_h3.erl` accumulates the HTTP/3 response body in memory without any size cap. The `after Timeout` clause is a per-message inactivity timer, not a wall-clock deadline: every received `stream_data` chunk, housekeeping `select` message, or `settings` frame resets it. A malicious HTTP/3 server that drips one small chunk every `Timeout - 1` ms with `Fin = false` and never terminates the stream keeps the loop alive indefinitely while the accumulation buffer grows without bound, eventually exhausting the BEAM process heap.\n\n### Details\n\nIn `src/hackney_h3.erl`, `await_response_loop/6` (line 430) builds the body with:\n\n```erlang\nNewBody = <<AccBody/binary, Data/binary>>\n```\n\nThere is no `max_body` check and no monotonic deadline. The `after Timeout` clause at line 463 is restarted on each loop iteration. A server that ensures at least one message arrives within `Timeout` ms indefinitely (one small chunk per interval is sufficient) prevents the timeout from firing while `AccBody` grows linearly. The same module's `wait_connected/3` (lines 388-389) shows the correct pattern: track an absolute start time and pass a shrinking `Remaining` budget into each `receive`. This loop does not.\n\n### Configurations\n\nOnly the HTTP/3 transport is affected. Applications using the default TCP/TLS hackney transport are not vulnerable. The vulnerability requires using `hackney_h3` directly or passing `{transport, h3}` to `hackney:request/5`.\n\n### PoC\n\n1. Stand up an HTTP/3 server that responds with `200 OK` headers (`Fin = false`), then emits a small `stream_data` chunk every `Timeout - margin` ms with `Fin = false` indefinitely.\n2. Issue `hackney:request(get, Url, [], <<>>, [{transport, h3}])` against it.\n3. Watch the client process heap grow monotonically. The configured timeout never fires; the process is eventually killed by `max_heap_size` or the OS OOM killer.\n\n### Impact\n\nRemote denial of service via unbounded memory consumption. Affects hackney 2.0.0 through 4.0.0 when using the HTTP/3 transport against an attacker-controlled or attacker-influenced server. Each affected request consumes unbounded memory until the BEAM is killed. CVSS v4.0: **8.2 (HIGH)**.\n\n## Resources\n\n* Introduction commit: https://github.com/benoitc/hackney/commit/0334af206d5099fdf510ed9eda18e34396f065ad\n* Patch commit: https://github.com/benoitc/hackney/commit/3d25f9fea26c90609de9d64366fedfe5065413bc","published":"2026-05-25T14:00:42.217Z","modified":"2026-10-21T02:30:44.571523570Z","cvss":null,"epss":{"score":0.00703,"percentile":0.51311,"asOf":"2026-09-13"},"cisaKev":null,"exploitsKnown":0,"affectedPackages":[{"ecosystem":"Hex","name":"hackney","fixedVersion":"4.0.1"}],"fix":{"url":"https://github.com/benoitc/hackney/commit/3d25f9fea26c90609de9d64366fedfe5065413bc","label":"benoitc/hackney@3d25f9f"},"references":[{"type":"WEB","url":"https://cna.erlef.org/cves/CVE-2026-47077.html"},{"type":"WEB","url":"https://github.com"},{"type":"WEB","url":"https://osv.dev/vulnerability/EEF-CVE-2026-47077"},{"type":"WEB","url":"https://repo.hex.pm"},{"type":"ADVISORY","url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/47xxx/CVE-2026-47077.json"},{"type":"ADVISORY","url":"https://github.com/benoitc/hackney/security/advisories/GHSA-jq4m-q6p2-8gwc"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-47077"},{"type":"FIX","url":"https://github.com/benoitc/hackney/commit/3d25f9fea26c90609de9d64366fedfe5065413bc"},{"type":"PACKAGE","url":"https://github.com/benoitc/hackney"},{"type":"WEB","url":"https://github.com/ex-aws/ex_aws_sns/security/advisories/GHSA-8jgf-23q5-x7xx"}],"provenance":{"sources":["OSV.dev","FIRST.org (EPSS)"],"lastVerified":"2026-10-21T02:30:44.571523570Z"}}