Description
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.
Published: 2026-05-25
Score: 8.7 High
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The vulnerability is a lack of resource limits in the WebSocket client of the hackney library. The client can accumulate data without bounds during handshake, large frames, or fragmented frames, which leads to memory exhaustion and potential denial of service. The weakness is a resource allocation without limits, classified as CWE‑400. An attacker who controls the WebSocket server can trigger the bug by sending data without the normal terminators or by declaring enormous payloads, causing the client to consume memory until the process crashes or the system becomes unresponsive.

Affected Systems

The hackney library, maintained by benoitc, is affected for all versions from 2.0.0 up to but excluding 4.0.1. Projects utilizing these versions and engaging in external WebSocket connections are at risk.

Risk and Exploitability

The CVSS score of 8.7 indicates high severity. No EPSS score is available, but resource‑limit exploitation is common and observable. The vulnerability is not listed in the CISA KEV catalog; nevertheless, because the attacker only needs to control the server, the attack vector is network‑based and does not require authentication or special privileges. If exploited, the client will run out of memory, terminate, and may deny service to the application depending on that connection.

Generated by OpenCVE AI on May 25, 2026 at 15:28 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Update hackney to version 4.0.1 or later
  • If upgrading is infeasible, place a proxy or firewall in front of the client that limits the maximum data rate or total data volume from untrusted WebSocket servers
  • Add application‑level logic to monitor and cap the buffer size used by hackney, or switch to an alternative WebSocket client that enforces size limits

Generated by OpenCVE AI on May 25, 2026 at 15:28 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Wed, 27 May 2026 14:00:00 +0000

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 7.5, 'vector': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H'}


Tue, 26 May 2026 16:30:00 +0000

Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'yes', 'Exploitation': 'poc', 'Technical Impact': 'partial'}, 'version': '2.0.3'}


Mon, 25 May 2026 14:30:00 +0000

Type Values Removed Values Added
Description 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.
Title Unbounded memory consumption in WebSocket client in hackney
First Time appeared Benoitc
Benoitc hackney
Weaknesses CWE-400
CPEs cpe:2.3:a:benoitc:hackney:*:*:*:*:*:*:*:*
Vendors & Products Benoitc
Benoitc hackney
References
Metrics cvssV4_0

{'score': 8.7, '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'}


cve-icon MITRE

Status: PUBLISHED

Assigner: EEF

Published:

Updated: 2026-05-27T15:41:30.606Z

Reserved: 2026-05-18T17:28:08.322Z

Link: CVE-2026-47073

cve-icon Vulnrichment

Updated: 2026-05-26T15:44:34.495Z

cve-icon NVD

Status : Analyzed

Published: 2026-05-25T15:16:22.410

Modified: 2026-05-27T13:54:21.643

Link: CVE-2026-47073

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-05-26T13:00:47Z

Weaknesses
  • CWE-400

    Uncontrolled Resource Consumption