CVE-2026-47077
HighCVSS 7.5Exploitation Probability (EPSS)
Low risk49th percentile - higher than 49% of all known CVEs
Summary
A vulnerability in the hackney library (versions 2.0.0 through 4.0.1) allows a Flooding attack due to missing size limits on the HTTP/3 response buffer. A malicious server can send small chunks, resetting the timeout, leading to unbounded memory growth and exhaustion of the BEAM process heap.
Risk Assessment
The attack can cause memory exhaustion and crash the application using hackney, resulting in denial of service (DoS).
Recommendation
Upgrade hackney to version 4.0.1 or later, which includes a fix that limits the response buffer size.
Other vulnerabilities in hackney
See all- CVE-2026-47076Medium
The hackney library for Erlang/OTP versions 0.13.0 through 4.0.1 contains a Server-Side Request Forgery (SSRF) vulnerability due to an interpretation conflict. The URL normalizer decodes the host after validation, allowing bypass of allowlists and access to internal IP addresses (e.g., 127.0.0.1, 169.254.169.254).
- CVE-2026-47075High
hackney before version 4.0.1 does not percent-encode CR (\r) and LF (\n) characters in the URL query component, enabling HTTP Request Splitting. An attacker controlling the URL can inject raw CRLF sequences into the query string, allowing arbitrary HTTP headers or request splitting.
- CVE-2026-47073High
A vulnerability in the hackney library (versions 2.0.0 through 4.0.1) allows memory exhaustion by an attacker-controlled WebSocket server. The WebSocket client does not limit buffer sizes in three code paths, enabling a Flooding attack.
- CVE-2026-47072High
CRLF Injection vulnerability in the hackney library allows an attacker to inject arbitrary HTTP headers into a WebSocket request. Lack of CRLF and NUL filtering at four injection points enables request manipulation, potentially leading to credential spoofing, cache poisoning, or request smuggling via proxies.
- CVE-2026-47071High
The hackney library versions 0.10.0 up to (but not including) 4.0.1 contains an uncontrolled resource consumption vulnerability in the SOCKS5 transport. After SOCKS5 negotiation, the connection is upgraded to TLS with an infinite timeout, allowing a malicious proxy to block the process indefinitely.
- CVE-2026-47070Medium
The hackney library versions 3.1.1 before 4.0.1 is vulnerable to sensitive data exposure. The HTTP/3 module (hackney_h3.erl) does not perform cross-origin checks on redirects, causing authorization headers and cookies to be sent to foreign hosts.
- CVE-2026-47069Medium
A CRLF Injection vulnerability was found in the hackney library (versions from 0.9.0 before 4.0.1) in the hackney_cookie:setcookie/3 function. An attacker controlling the domain or path option can inject a CRLF sequence and arbitrary Set-Cookie headers, leading to HTTP Response Splitting.
- CVE-2026-47067High
The hackney library versions 2.0.0 up to (but not including) 4.0.1 contains a vulnerability that exhausts the BEAM atom table. The URL parser converts unrecognized URL schemes to atoms via binary_to_atom/2, which are never garbage-collected. An attacker can supply many URLs with unique schemes, exceeding the atom table limit and crashing the entire BEAM VM.
- CVE-2026-47066High
The hackney library versions 2.0.0-beta.1 up to (but not including) 4.0.1 contains an infinite loop vulnerability in the Alt-Svc header parser. The parse_token/2 function does not guarantee forward progress for certain bytes, leading to a recursive loop consuming 100% CPU. An Alt-Svc: ! header is sufficient to trigger the vulnerability.
Original NVD description (English source)
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.