GitHub Advisoryadvisory · Hex

GHSA-q8jg-fgj4-fphf Hackney has unbounded buffer accumulation in WebSocket

HIGH Published 2026-06-26 Modified 2026-06-26 Official page ↗
Aliases
CVE-2026-47073
Ecosystem
Hex
Packages
hackney
Severity
High
CVSS vector
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
Weaknesses
CWE-400
Reviewed
2026-06-26

Affected packages

• Hex hackney: >= 2.0.0, < 4.0.1 → fixed in 4.0.1

Description

Summary The WebSocket client in `src/hackney_ws.erl` imposes no upper bound on memory consumption across three distinct code paths. In each case, an attacker-controlled WebSocket server can exhaust the connecting process's memory without any authentication or special client configuration. Details 1. Handshake response buffer (`read_handshake_response/3`) The function accumulates received bytes into a growing buffer waiting for `\r\n\r\n`. The per-receive timeout resets on every chunk, so a server that trickles bytes indefinitely without completing the HTTP upgrade response grows the buffer until OOM. No total-size cap exists. 2. Frame payload accumulation (`parse_payload/9`, `parse_active_payload/8`) `parse_payload/9` (lines 816–817 and 825–826) appends each received chunk into a `Buffer` binary via `>` whenever the frame parser returns `{more, ...}`. `parse_active_payload/8` does the same in active mode by appending each incoming `tcp`/`ssl` message to `#ws_data.buffer`. RFC 6455 permits payload lengths up to 2⁶³-1 bytes, and neither path validates the declared `Len` against any limit. The `recv_timeout` applies per chunk, not to the whole frame, so a slow trickle never triggers it. 3. Fragmentation buffer (`frag_buffer`) The `frag_buffer` field of `#ws_data{}` accumulates continuation frames. A server that sends an unbounded stream of non-final (`nofin`) fragments without ever sending a final (`fin`) frame grows `frag_buffer` without bound. PoC 1. Stand up a WebSocket server and connect to it with hackney's WebSocket client. 2. Trigger any of the three paths: (a) never send `\r\n\r\n` during the handshake; (b) announce a very large frame payload and dribble bytes slowly; (c) send an endless stream of `nofin` continuation frames. 3. Observe the hackney process's memory growing until the BEAM OOM-kills it or the node crashes. Impact Denial of service via unbounded memory consumption. Affects hackney 2.0.0 through 4.0.0 for any application using the WebSocket client against an attacker-controlled server. No authentication or special configuration is required on the client side. CVSS v4.0: 8.7 (HIGH). Resources • Introduction commit: https://github.com/benoitc/hackney/commit/690cecaf236fba49526da404a5bc889a24367a3e • Patch commit: https://github.com/benoitc/hackney/commit/ce0109e2970ace6e20ff29bae9d05c3ac22ec6dc

Related

Alias · CVE (1)

  • CVE-2026-47073 Allocation of Resources Without Limits or Throttling vulnerability in benoitc hackney allows Flooding. vulnerability

Weakness · CWE (1)

  • CWE-400 Uncontrolled Resource Consumption weakness

References