EUVD-2026-31688
GHSA-76v6-f83q-pxvh
Severity by source
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
AC:H because the client must use the non-default HTTP/3 transport and reach an attacker-influenced server; PR:N/UI:N as no auth or interaction beyond the request; impact is availability-only (A:H), with C/I:N.
Primary rating from Vendor (EEF).
CVSS VectorVendor: EEF
Lifecycle Timeline
4DescriptionCVE.org
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.
This issue affects hackney: from 2.0.0 before 4.0.1.
AnalysisAI
Remote denial of service in benoitc hackney 2.0.0 through 4.0.0 lets a malicious HTTP/3 server exhaust a client's BEAM process memory by trickling response chunks. The hackney_h3:await_response_loop/6 function buffers the entire HTTP/3 body in memory with no size cap while its 'after Timeout' guard behaves as a per-message inactivity timer that any incoming chunk resets, so a server that emits one small chunk just before each timeout and never sends Fin keeps the loop alive while the buffer grows without bound. Publicly available exploit code exists and a vendor patch (4.0.1) is released, but EPSS is only 0.04% and the flaw is not in CISA KEV, so it is not confirmed actively exploited.
Technical ContextAI
hackney is a widely used HTTP client library for the Erlang/Elixir (BEAM) ecosystem. The bug is confined to its HTTP/3 transport module src/hackney_h3.erl. Root cause is CWE-400 (Uncontrolled Resource Consumption / Allocation of Resources Without Limits or Throttling): await_response_loop/6 concatenates each received stream_data chunk with NewBody = <<AccBody/binary, Data/binary>> and never checks a maximum body size, while the receive loop's 'after Timeout' clause is restarted on every iteration rather than measured against an absolute deadline. Because the timer is reset by any stream_data chunk, housekeeping 'select' message, or 'settings' frame, it is an inactivity timer, not a wall-clock deadline. The same module already contained the correct pattern in wait_connected/3 (tracking an absolute start time and passing a shrinking Remaining budget), which was not applied to the response loop. On the BEAM, unbounded binary accumulation grows the process heap until max_heap_size or the OS OOM killer terminates the process.
RemediationAI
Vendor-released patch: upgrade hackney to 4.0.1, which introduces an absolute wall-clock deadline for the whole response and a default 512 MiB (0x20000000) cap on the buffered body via the new max_body_size option (fix commit 3d25f9fea26c90609de9d64366fedfe5065413bc, advisory GHSA-jq4m-q6p2-8gwc). If you cannot upgrade immediately, avoid the vulnerable code path by not using the HTTP/3 transport - do not pass {transport, h3} to hackney:request/5 and do not call hackney_h3 directly, so requests use the unaffected default TCP/TLS transport, at the cost of losing HTTP/3 support. Where HTTP/3 is required, restrict which servers clients may connect to (allowlist trusted endpoints) so an attacker cannot influence the request target, and on 4.0.1+ set an explicit conservative max_body_size while relying on the wall-clock timeout; for legitimately very large downloads, use hackney's streaming API instead of the buffered await path so the body is not held entirely in memory.
Denial of service in benoitc hackney (Erlang HTTP client) versions 2.0.0 through 4.0.0 allows a malicious WebSocket serv
Denial of service in benoitc hackney (Erlang HTTP client) 2.0.0 through 4.0.0 allows remote unauthenticated attackers to
Denial-of-service in benoitc's hackney Erlang HTTP client (versions 2.0.0-beta.1 through 4.0.0) allows any HTTP origin s
Denial of service in benoitc hackney (Erlang HTTP client) versions 0.10.0 through 4.0.0 lets a hostile SOCKS5 or HTTP CO
CRLF injection in hackney (Erlang HTTP client, versions 2.0.0-4.0.1) enables header injection into outbound WebSocket up
SSRF allowlist bypass in hackney (Erlang HTTP client) versions 0.13.0 through before 4.0.1 allows attackers who control
HTTP Request Splitting via CRLF injection in hackney, the Erlang/Elixir HTTP client library, allows an attacker who cont
Credential leakage in the hackney Erlang HTTP client library (versions 3.1.1 through before 4.0.1) allows a malicious or
CRLF injection in the hackney Erlang HTTP client library's hackney_cookie:setcookie/3 function enables HTTP response spl
Same weakness CWE-400 – Uncontrolled Resource Consumption
View allSame technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today