CVE-2026-47073
published 2026-05-25CVE-2026-47073: Allocation of Resources Without Limits or Throttling vulnerability in benoitc hackney allows Flooding. The WebSocket client in src/hackney_ws.erl imposes no…
PriorityP349high7.5CVSS 3.1
AVNACLPRNUINSUCNINAH
EPSS
0.83%
53.6th percentile
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.
Affected
4 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| benoitc | hackney | >= 2.0.0 < 4.0.1 | 4.0.1 |
| benoitc | hackney | >= 2.0.0 < 4.0.1 | 4.0.1 |
| benoitc | hackney | >= 2.0.0 < 4.0.1 | 4.0.1 |
| benoitc | hackney | >= 690cecaf236fba49526da404a5bc889a24367a3e < ce0109e2970ace6e20ff29bae9d05c3ac22ec6dc | ce0109e2970ace6e20ff29bae9d05c3ac22ec6dc |
CVSS provenance
nvdv3.17.5HIGHCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
nvdv4.08.7HIGHCVSS: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
cvelistv5v4.08.7HIGHCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
GHSA
Hackney has unbounded buffer accumulation in WebSocket
ghsa·2026-06-26
CVE-2026-47073 [HIGH] CWE-400 Hackney has unbounded buffer accumulation in WebSocket
Hackney has unbounded buffer accumulation in WebSocket
### 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_paylo
CVEList
Unbounded memory consumption in WebSocket client in hackney
cvelistv5·2026-05-25·CVSS 8.7
CVE-2026-47073 [HIGH] CWE-400 Unbounded memory consumption in WebSocket client in hackney
Unbounded memory consumption in WebSocket client in hackney
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
VulDB
benoitc hackney up to 4.0.0 src/hackney_ws.erl frag_buffer resource consumption (EUVD-2026-31694)
vuldb·2026-05-25
CVE-2026-47073 [LOW] benoitc hackney up to 4.0.0 src/hackney_ws.erl frag_buffer resource consumption (EUVD-2026-31694)
A vulnerability identified as problematic has been detected in benoitc hackney up to 4.0.0. Affected is an unknown function of the file src/hackney_ws.erl. The manipulation of the argument frag_buffer leads to resource consumption.
This vulnerability is uniquely identified as CVE-2026-47073. The attack is possible to be carried out remotely. No exploit exists.
You should upgrade the affected component.
No detection rules found.
No public exploits indexed.
No writeups or analysis indexed.
https://cna.erlef.org/cves/CVE-2026-47073.htmlhttps://github.com/benoitc/hackney/commit/ce0109e2970ace6e20ff29bae9d05c3ac22ec6dchttps://github.com/benoitc/hackney/security/advisories/GHSA-q8jg-fgj4-fphfhttps://osv.dev/vulnerability/EEF-CVE-2026-47073https://github.com/benoitc/hackney/security/advisories/GHSA-q8jg-fgj4-fphf
2026-05-25
Published