CVE-2026-47073
HighCVSS 7.5Exploitation Probability (EPSS)
Elevated risk54th percentile - higher than 54% of all known CVEs
Summary
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.
Risk Assessment
An attacker can cause a denial of service (DoS) by exhausting the memory of the hackney client process, without requiring authentication.
Recommendation
Update the hackney library to version 4.0.1 or later.
Other vulnerabilities in hackney
See all- CVE-2026-47077High
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.
- 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-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. The WebSocket client in src/hackney_ws.erl imposes no upper bound on memory consumption in three code paths. First, read_handshake_response/3 accumulates received bytes into a growing buffer with no size cap; the per-receive timeout resets on every chunk, so a server that streams bytes without ever sending \r\n\r\n causes the buffer to grow until memory is exhausted. Second, parse_payload/9 and parse_active_payload/8 do not validate the declared frame payload length against any limit; because RFC 6455 allows payload lengths up to 2^63-1 bytes, a server that announces a very large frame and dribbles bytes causes the accumulation buffer to grow until OOM. Third, the frag_buffer field in #ws_data{} accumulates continuation frames indefinitely; a server that sends an endless stream of non-final (nofin) fragmented frames without ever sending a final (fin) frame grows frag_buffer without bound. In all three cases the attacker only needs to control the WebSocket server the hackney client connects to, with no authentication or special client configuration required. This issue affects hackney: from 2.0.0 before 4.0.1.