Summary
Hackney: Per-chunk timeout with unbounded body accumulation enables slow-drip OOM
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.
Details
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.
Configurations
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.
PoC
- Stand up an HTTP/3 server that responds with
200 OKheaders (Fin = false), then emits a smallstream_datachunk everyTimeout - marginms withFin = falseindefinitely. - Issue
hackney:request(get, Url, [], <<>>, [{transport, h3}])against it. - Watch the client process heap grow monotonically. The configured timeout never fires; the process is eventually killed by
max_heap_sizeor the OS OOM killer.
Resources
Impact
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).
Crafted input forces the application to consume excessive CPU, memory, or other resources, degrading or denying service. Typical impact: denial of service.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is CVE-2026-47077? CVE-2026-47077 is a high-severity uncontrolled resource consumption vulnerability in hackney (erlang), affecting versions >= 2.0.0, < 4.0.1. It is fixed in 4.0.1. Crafted input forces the application to consume excessive CPU, memory, or other resources, degrading or denying service.
- Which versions of hackney are affected by CVE-2026-47077? hackney (erlang) versions >= 2.0.0, < 4.0.1 is affected.
- Is there a fix for CVE-2026-47077? Yes. CVE-2026-47077 is fixed in 4.0.1. Upgrade to this version or later.
- Is CVE-2026-47077 exploitable, and should I be worried? Whether CVE-2026-47077 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-47077 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-47077? Upgrade
hackneyto 4.0.1 or later.