CVE-2026-47077High▾ TwilightHackney: Per-chunk timeout with unbounded body accumulation enables slow-drip OOM
▾ Twilight zone — High severity, or a signal on a lesser flaw
impact 41.3 · likelihood 0.1 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Exploit-prediction probability, daily snapshots since Jul 4.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via GHSA
Last analysed / modified upstream
0.7%
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.
In src/hackney_h3.erl, await_response_loop/6 (line 430) builds the body with:
NewBody = <<AccBody/binary, Data/binary>>
There 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.
Only 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.
200 OK headers (Fin = false), then emits a small stream_data chunk every Timeout - margin ms with Fin = false indefinitely.hackney:request(get, Url, [], <<>>, [{transport, h3}]) against it.max_heap_size or the OS OOM killer.Remote 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).
hackney >= 2.0.0, < 4.0.1Upgrade to a patched release:
hackney 4.0.1Connected by shared product, vendor, weakness, or advisory.
CVE-2026-47074HighHackney: Per-chunk timeout with unbounded body accumulation enables slow-drip OOM
CVE-2026-47071HighHackney: `ssl:connect/2` post-handshake upgrade has no timeout
CVE-2026-47073HighHackney has unbounded buffer accumulation in WebSocket
GHSA-8jgf-23q5-x7xxHighex_aws_sns: Trusted-attacker `SigningCertURL` permits complete SNS signature bypass
CVE-2026-24281High· 7.4Hostname verification in Apache ZooKeeper ZKTrustManager falls back to reverse DNS (PTR) when IP SAN validation fails, allowing attackers who control or spoof PTR records to impersonate ZooKeeper servers or clients with a valid certifica…
CVE-2026-47066HighHackney has an infinite loop on non-token byte at start of an Alt-Svc entry