EUVD-2026-31694
GHSA-q8jg-fgj4-fphf
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/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
Primary rating from NVD · only source for this CVE.
CVSS VectorNVD
CVSS:4.0/AV:N/AC:L/AT:N/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
Lifecycle Timeline
4DescriptionCVE.org
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.
AnalysisAI
Denial of service in benoitc hackney (Erlang HTTP client) versions 2.0.0 through 4.0.0 allows a malicious WebSocket server to exhaust client memory via three unbounded buffer paths in src/hackney_ws.erl. An attacker controlling the server the hackney client connects to can drive the Erlang VM to OOM by streaming bytes without terminator, declaring a giant RFC 6455 frame length, or sending endless non-final continuation fragments. Publicly available exploit code exists per SSVC, EPSS is low at 0.09%, and a vendor patch is available in 4.0.1.
Technical ContextAI
hackney is a widely used Erlang HTTP/WebSocket client library maintained by Benoît Chesneau. The vulnerability is a classic CWE-400 (Uncontrolled Resource Consumption) in the WebSocket client state machine. Three specific code paths in src/hackney_ws.erl lacked size caps: read_handshake_response/3 accumulated bytes until the \r\n\r\n terminator with the per-receive timeout resetting on every chunk; parse_payload/9 and parse_active_payload/8 trusted the declared RFC 6455 frame length (which permits up to 2^63-1 bytes) without validation; and the frag_buffer field in #ws_data{} grew indefinitely as non-final continuation frames arrived. CPE coverage (cpe:2.3:a:benoitc:hackney:*) confirms all versions in the 2.0.0-4.0.0 range are affected.
RemediationAI
Vendor-released patch: upgrade hackney to 4.0.1 or later, which introduces DEFAULT_MAX_FRAME_SIZE (16 MiB), DEFAULT_MAX_MESSAGE_SIZE (64 MiB), and MAX_HANDSHAKE_RESPONSE_SIZE (64 KiB) caps per commit ce0109e2970ace6e20ff29bae9d05c3ac22ec6dc; the new max_frame_size and max_message_size options can be tuned per connection if defaults are too restrictive. Refer to the advisory at https://github.com/benoitc/hackney/security/advisories/GHSA-q8jg-fgj4-fphf and the patch commit at https://github.com/benoitc/hackney/commit/ce0109e2970ace6e20ff29bae9d05c3ac22ec6dc. If immediate upgrade is not possible, restrict WebSocket client connections to a vetted allowlist of trusted servers, validate any user-supplied WebSocket URLs before passing them to hackney (preventing SSRF-style abuse), and apply per-process memory limits or Erlang VM memory ceilings to contain runaway growth - noting that hard limits will crash the connecting process rather than gracefully reject the malicious server.
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
Allocation of Resources Without Limits or Throttling vulnerability in benoitc hackney allows Flooding. hackney_h3:await_
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