CVE-2026-47073
Analyzed Analyzed - Analysis Complete
Memory Exhaustion in hackney WebSocket Client

Publication date: 2026-05-25

Last updated on: 2026-05-27

Assigner: EEF

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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-25
Last Modified
2026-05-27
Generated
2026-06-15
AI Q&A
2026-05-26
EPSS Evaluated
2026-06-14
NVD
CVE-2026-47073
EUVD
EUVD-2026-31694
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
benoitc hackney From 2.0.0 (inc) to 4.0.1 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-400 The product does not properly control the allocation and maintenance of a limited resource.
Attack-Flow Graph
AI Quick Actions
Instant insights powered by AI
Executive Summary

This vulnerability is an Allocation of Resources Without Limits or Throttling issue in the benoitc hackney WebSocket client. It allows an attacker controlling the WebSocket server to cause the client to consume unlimited memory, leading to a potential denial of service.

Specifically, there are three code paths where memory usage is unbounded: first, the handshake response accumulates bytes into a buffer without size limits; second, frame payload lengths are not validated against any maximum size, allowing very large frames to exhaust memory; third, continuation frames accumulate indefinitely if a final frame is never sent.

No authentication or special client configuration is needed by the attacker, only control of the WebSocket server the client connects to.

Impact Analysis

This vulnerability can lead to a denial of service condition by exhausting the memory of the client application using the hackney WebSocket client. An attacker controlling the WebSocket server can cause the client to consume excessive memory, potentially crashing the client or degrading its performance.

Compliance Impact

The provided information does not specify any direct impact of this vulnerability on compliance with common standards and regulations such as GDPR or HIPAA.

Detection Guidance

This vulnerability manifests as unbounded memory growth in the hackney WebSocket client when connecting to a malicious WebSocket server. Detection involves monitoring the memory usage of applications using hackney versions 2.0.0 up to but not including 4.0.1, especially during WebSocket connections.

You can detect potential exploitation by observing unusually high or steadily increasing memory consumption in the process running the hackney client.

Suggested commands to monitor memory usage on a system include:

  • Linux: Use `top`, `htop`, or `ps aux --sort=-rss | head` to identify processes with high memory usage.
  • Use `lsof -p <pid>` to check open network connections of the suspected process.
  • Use network monitoring tools like `tcpdump` or `wireshark` to inspect WebSocket traffic for abnormal or continuous streaming data without proper termination sequences.

Since the vulnerability involves the client accumulating data indefinitely from a malicious server, detecting long-lived WebSocket connections with continuous data flow and increasing memory usage is key.

Mitigation Strategies

The primary mitigation is to upgrade the hackney library to version 4.0.1 or later, where this vulnerability has been fixed.

The fix introduces configurable limits on buffer sizes to prevent unbounded memory growth:

  • max_frame_size (default 16 MiB) limits the size of individual frames.
  • max_message_size (default 64 MiB) limits the cumulative size of fragmented messages.
  • A fixed 64 KiB limit on the handshake response buffer.

If upgrading immediately is not possible, consider monitoring and limiting memory usage of the affected processes and restricting connections to untrusted WebSocket servers.

Additionally, configure the new limits if possible to suit your environment, and abort connections that exceed these limits to prevent memory exhaustion.

Chat Assistant
Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-47073. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70
EPSS Chart