{"id":"CVE-2026-47077","aliases":["EEF-CVE-2026-47077","EUVD-2026-31688","GHSA-76v6-f83q-pxvh","GHSA-jq4m-q6p2-8gwc"],"status":"published","title":"Unbounded body accumulation in HTTP/3 response loop in hackney","description":"Allocation of Resources Without Limits or Throttling vulnerability in benoitc hackney allows Flooding. hackney_h3:await_response_loop/6 accumulates the HTTP/3 response body in memory without any size cap. The after Timeout clause is a per-message inactivity timer that resets on every received chunk, housekeeping message, or settings frame — it is not a wall-clock deadline. A malicious HTTP/3 server that emits one small chunk every Timeout - 1 ms with Fin = false and never sends a final frame keeps the loop alive indefinitely while the accumulation buffer grows linearly without bound, eventually exhausting the BEAM process heap and causing an out-of-memory condition.\n\nThis issue affects hackney: from 2.0.0 before 4.0.1.","severity":{"version":"4.0","score":8.2,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-11","score":0.00703,"percentile":0.53728,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-295","CWE-400"],"published":"2026-05-25T14:00:42Z","modified":"2026-10-28T02:30:27Z","fixes":[{"ecosystem":"Hex","package":"hackney","fixed_in":["4.0.1"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"Hex","package":"hackney","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"2.0.0"},{"fixed":"4.0.1"}]}]},{"source":"osv","ecosystem":"Hex","package":"hackney","ranges":[{"type":"SEMVER","events":[{"introduced":"2.0.0"},{"fixed":"4.0.1"}]}],"versions":["2.0.0","2.0.1","3.0.0","3.0.1","3.0.2","3.0.3","3.1.0","3.1.1","3.1.2","3.2.0","3.2.1","4.0.0"]},{"source":"osv","ecosystem":"Hex","package":"hackney","ranges":[{"type":"SEMVER","events":[{"introduced":"2.0.0"},{"fixed":"4.0.1"}]}],"versions":["2.0.0","2.0.1","3.0.0","3.0.1","3.0.2","3.0.3","3.1.0","3.1.1","3.1.2","3.2.0","3.2.1","4.0.0"]}],"products":[{"vendor":"benoitc","product":"hackney"},{"vendor":"hackney","product":"hackney"}],"references":[{"url":"https://github.com/benoitc/hackney/security/advisories/GHSA-jq4m-q6p2-8gwc","tags":["vendor-advisory","related","exploit","Exploit","Patch","Vendor Advisory","advisory","web"]},{"url":"https://cna.erlef.org/cves/CVE-2026-47077.html","tags":["related","Patch","Third Party Advisory","web"]},{"url":"https://osv.dev/vulnerability/EEF-CVE-2026-47077","tags":["related","Patch","Third Party Advisory","web"]},{"url":"https://github.com/benoitc/hackney/commit/3d25f9fea26c90609de9d64366fedfe5065413bc","tags":["patch","Patch","fix","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-47077","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-76v6-f83q-pxvh"},{"url":"https://github.com/ex-aws/ex_aws_sns/security/advisories/GHSA-8jgf-23q5-x7xx","tags":["web"]},{"url":"https://github.com/advisories/GHSA-jq4m-q6p2-8gwc"},{"url":"https://github.com","tags":["web"]},{"url":"https://repo.hex.pm","tags":["web"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/47xxx/CVE-2026-47077.json","tags":["advisory"]},{"url":"https://github.com/benoitc/hackney","tags":["package"]},{"url":"https://hex.pm/packages/hackney","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-47077","title":"Unbounded body accumulation in HTTP/3 response loop in hackney","description":"Allocation of Resources Without Limits or Throttling vulnerability in benoitc hackney allows Flooding. hackney_h3:await_response_loop/6 accumulates the HTTP/3 response body in memory without any size cap. The after Timeout clause is a per-message inactivity timer that resets on every received chunk, housekeeping message, or settings frame — it is not a wall-clock deadline. A malicious HTTP/3 server that emits one small chunk every Timeout - 1 ms with Fin = false and never sends a final frame keeps the loop alive indefinitely while the accumulation buffer grows linearly without bound, eventually exhausting the BEAM process heap and causing an out-of-memory condition.\n\nThis issue affects hackney: from 2.0.0 before 4.0.1.","status":"published","published":"2026-05-25T14:00:42.217Z","modified":"2026-05-27T15:40:53.384Z","cvss":[{"version":"4.0","score":8.2,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"high","assessor":"cna"}],"cwes":["CWE-400"],"updated_at":"2026-11-02T13:36:29.327819Z"}],"euvd":[{"id":"EUVD-2026-31688","description":"Allocation of Resources Without Limits or Throttling vulnerability in benoitc hackney allows Flooding. hackney_h3:await_response_loop/6 accumulates the HTTP/3 response body in memory without any size cap. The after Timeout clause is a per-message inactivity timer that resets on every received chunk, housekeeping message, or settings frame — it is not a wall-clock deadline. A malicious HTTP/3 server that emits one small chunk every Timeout - 1 ms with Fin = false and never sends a final frame keeps the loop alive indefinitely while the accumulation buffer grows linearly without bound, eventually exhausting the BEAM process heap and causing an out-of-memory condition.\n\nThis issue affects hackney: from 2.0.0 before 4.0.1.","status":"published","published":"2026-05-25T14:00:42Z","modified":"2026-05-27T15:40:53Z","cvss":[{"version":"4.0","score":8.2,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"high"}],"updated_at":"2026-11-02T18:21:03.926243Z"}],"ghsa":[{"id":"GHSA-76v6-f83q-pxvh","title":"Duplicate Advisory: Hackney has an Allocation of Resources Without Limits or Throttling vulnerabilit","description":"## Duplicate Advisory\n\nThis advisory has been withdrawn because it is a duplicate of GHSA-jq4m-q6p2-8gwc. This link is maintained to preserve external references.\n\n## Original Description\nAllocation of Resources Without Limits or Throttling vulnerability in benoitc hackney allows Flooding. hackney_h3:await_response_loop/6 accumulates the HTTP/3 response body in memory without any size cap. The after Timeout clause is a per-message inactivity timer that resets on every received chunk, housekeeping message, or settings frame — it is not a wall-clock deadline. A malicious HTTP/3 server that emits one small chunk every Timeout - 1 ms with Fin = false and never sends a final frame keeps the loop alive indefinitely while the accumulation buffer grows linearly without bound, eventually exhausting the BEAM process heap and causing an out-of-memory condition.\n\nThis issue affects hackney: from 2.0.0 before 4.0.1.","status":"withdrawn","published":"2026-05-26T13:30:46Z","modified":"2026-06-30T17:15:57Z","cvss":[{"version":"4.0","score":8.2,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"high"},{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high"}],"cwes":["CWE-400"],"updated_at":"2026-11-02T14:40:35.701766Z"},{"id":"GHSA-jq4m-q6p2-8gwc","title":"Hackney: Per-chunk timeout with unbounded body accumulation enables slow-drip OOM","description":"### 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 = \u003c\u003cAccBody/binary, Data/binary\u003e\u003e\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, [], \u003c\u003c\u003e\u003e, [{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","status":"published","published":"2026-06-26T21:57:33Z","modified":"2026-06-30T17:16:10Z","cvss":[{"version":"4.0","score":8.2,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"high"}],"cwes":["CWE-295","CWE-400"],"updated_at":"2026-11-02T14:40:35.701766Z"}],"nvd":[{"id":"CVE-2026-47077","description":"Allocation of Resources Without Limits or Throttling vulnerability in benoitc hackney allows Flooding. hackney_h3:await_response_loop/6 accumulates the HTTP/3 response body in memory without any size cap. The after Timeout clause is a per-message inactivity timer that resets on every received chunk, housekeeping message, or settings frame — it is not a wall-clock deadline. A malicious HTTP/3 server that emits one small chunk every Timeout - 1 ms with Fin = false and never sends a final frame keeps the loop alive indefinitely while the accumulation buffer grows linearly without bound, eventually exhausting the BEAM process heap and causing an out-of-memory condition.\n\nThis issue affects hackney: from 2.0.0 before 4.0.1.","status":"published","published":"2026-05-25T15:16:22.837Z","modified":"2026-07-24T10:10:00.197Z","cvss":[{"version":"4.0","score":8.2,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"high","assessor":"secondary"},{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high","assessor":"primary"}],"cwes":["CWE-400"],"updated_at":"2026-11-02T14:12:20.131508Z"}],"osv":[{"id":"CVE-2026-47077","title":"Unbounded body accumulation in HTTP/3 response loop in hackney","description":"Allocation of Resources Without Limits or Throttling vulnerability in benoitc hackney allows Flooding. hackney_h3:await_response_loop/6 accumulates the HTTP/3 response body in memory without any size cap. The after Timeout clause is a per-message inactivity timer that resets on every received chunk, housekeeping message, or settings frame — it is not a wall-clock deadline. A malicious HTTP/3 server that emits one small chunk every Timeout - 1 ms with Fin = false and never sends a final frame keeps the loop alive indefinitely while the accumulation buffer grows linearly without bound, eventually exhausting the BEAM process heap and causing an out-of-memory condition.\n\nThis issue affects hackney: from 2.0.0 before 4.0.1.","status":"published","published":"2026-05-25T14:00:42.217Z","modified":"2026-10-28T02:30:27.944182899Z","cvss":[{"version":"4.0","score":8.2,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"high"}],"cwes":["CWE-400"],"updated_at":"2026-11-02T15:45:06.231145Z"},{"id":"EEF-CVE-2026-47077","title":"Unbounded body accumulation in HTTP/3 response loop in hackney","description":"## Summary\n\nAllocation of Resources Without Limits or Throttling vulnerability in benoitc hackney allows Flooding. hackney\\_h3:await\\_response\\_loop/6 accumulates the HTTP/3 response body in memory without any size cap. The after Timeout clause is a per-message inactivity timer that resets on every received chunk, housekeeping message, or settings frame — it is not a wall-clock deadline. A malicious HTTP/3 server that emits one small chunk every Timeout - 1 ms with Fin = false and never sends a final frame keeps the loop alive indefinitely while the accumulation buffer grows linearly without bound, eventually exhausting the BEAM process heap and causing an out-of-memory condition.\n\nThis issue affects hackney: from 2.0.0 before 4.0.1.\n\n## Configurations\n\nThe application must use the HTTP/3 transport by calling hackney\\_h3 directly or by passing {transport, h3} to hackney:request/5. The default hackney transport (TCP/TLS) is not affected.","status":"published","published":"2026-05-25T14:00:42.217Z","modified":"2026-09-08T03:30:11.372329098Z","cvss":[{"version":"4.0","score":8.2,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"high"}],"cwes":["CWE-400"],"updated_at":"2026-11-02T15:46:33.047032Z"},{"id":"GHSA-76v6-f83q-pxvh","title":"Duplicate Advisory: Hackney has an Allocation of Resources Without Limits or Throttling vulnerabilit","description":"## Duplicate Advisory\n\nThis advisory has been withdrawn because it is a duplicate of GHSA-jq4m-q6p2-8gwc. This link is maintained to preserve external references.\n\n## Original Description\nAllocation of Resources Without Limits or Throttling vulnerability in benoitc hackney allows Flooding. hackney_h3:await_response_loop/6 accumulates the HTTP/3 response body in memory without any size cap. The after Timeout clause is a per-message inactivity timer that resets on every received chunk, housekeeping message, or settings frame — it is not a wall-clock deadline. A malicious HTTP/3 server that emits one small chunk every Timeout - 1 ms with Fin = false and never sends a final frame keeps the loop alive indefinitely while the accumulation buffer grows linearly without bound, eventually exhausting the BEAM process heap and causing an out-of-memory condition.\n\nThis issue affects hackney: from 2.0.0 before 4.0.1.","status":"withdrawn","published":"2026-05-26T13:30:46Z","modified":"2026-09-10T03:50:46.082386095Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high"},{"version":"4.0","score":8.2,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"high"}],"cwes":["CWE-400"],"updated_at":"2026-11-02T15:46:40.657155Z"},{"id":"GHSA-jq4m-q6p2-8gwc","title":"Hackney: Per-chunk timeout with unbounded body accumulation enables slow-drip OOM","description":"### 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 = \u003c\u003cAccBody/binary, Data/binary\u003e\u003e\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, [], \u003c\u003c\u003e\u003e, [{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","status":"published","published":"2026-06-26T21:57:33Z","modified":"2026-06-30T17:41:30.899031298Z","cvss":[{"version":"4.0","score":8.2,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"high"}],"cwes":["CWE-295","CWE-400"],"updated_at":"2026-11-02T15:46:50.687609Z"}]}}