CVE-2026-47073: Unbounded memory consumption in WebSocket client in hackney
Summary
The WebSocket client in src/hackneyws.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 (readhandshakeresponse/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 (parsepayload/9, parseactivepayload/8)
parsepayload/9 (lines 816–817 and 825–826) appends each received chunk into a Buffer binary via <<Buffer/binary, MoreData/binary>> whenever the frame parser returns {more, ...}. parseactivepayload/8 does the same in active mode by appending each incoming tcp/ssl message to #wsdata.buffer. RFC 6455 permits payload lengths up to 2⁶³-1 bytes, and neither path validates the declared Len against any limit. The recvtimeout applies per chunk, not to the whole frame, so a slow trickle never triggers it.
3. Fragmentation buffer (fragbuffer)
The fragbuffer field of #wsdata{} accumulates continuation frames. A server that sends an unbounded stream of non-final (nofin) fragments without ever sending a final (fin) frame grows fragbuffer 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
Other sources
Allocation of Resources Without Limits or Throttling vulnerability in benoitc hackney allows Flooding. The WebSocket client in src/hackneyws.erl imposes no upper bound on memory consumption in three code paths. First, readhandshakeresponse/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, parsepayload/9 and parseactivepayload/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 fragbuffer field in #wsdata{} 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 fragbuffer 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.
— NVD
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
erlang/hackneyto a version that resolves this vulnerability.Fixed in 4.0.1 - Upgrade
Upgrade
benoitc/hackneyto a version that resolves this vulnerability.Fixed in 4.0.1 - Compensating control
Mitigate the denial-of-service by ensuring the WebSocket client connects only to servers you control or trust (attacker-controlled WebSocket servers can exhaust memory by streaming without authentication or special client configuration).
- Operational
After remediation, restart/redispatch affected BEAM nodes/processes if they experienced OOM-kills or crashes due to unbounded websocket buffer growth.
Event History
Frequently Asked Questions
What is the severity of CVE-2026-47073?
CVE-2026-47073 has a risk score of 54, indicating a moderate severity due to unbounded memory consumption.
How do I fix CVE-2026-47073?
To mitigate CVE-2026-47073, update to the latest version of the hackney library where the vulnerability has been addressed.
What component is affected by CVE-2026-47073?
CVE-2026-47073 affects the WebSocket client implementation in the hackney library.
Can CVE-2026-47073 lead to denial of service?
Yes, CVE-2026-47073 allows for denial of service through memory flooding due to lack of limits in resource allocation.
Who is responsible for CVE-2026-47073?
The vulnerability is found in the benoitc/hackney library, which is maintained by the community.