CVE-2026-47073: Benoitc Hackney DoS Vulnerability

CVE-2026-47073 Overview

CVE-2026-47073 is a resource exhaustion vulnerability in benoitc/hackney, an HTTP client library widely used in the Erlang ecosystem. The WebSocket client implementation in src/hackney_ws.erl fails to enforce upper bounds on memory consumption across three distinct code paths. A malicious WebSocket server that a hackney client connects to can drive the client process to out-of-memory (OOM) conditions without authentication or special client configuration. The flaw is classified under CWE-400: Uncontrolled Resource Consumption and affects hackney versions from 2.0.0 before 4.0.1.

Critical Impact
A hostile WebSocket server can exhaust client memory and crash any Erlang/Elixir application that uses hackney to initiate WebSocket connections.

Affected Products

benoitc hackney 2.0.0 through 4.0.0
Erlang/Elixir applications embedding hackney as an HTTP/WebSocket client
Downstream libraries depending on hackney for outbound WebSocket connectivity

Discovery Timeline

2026-05-25 - CVE-2026-47073 published to NVD
2026-05-27 - Last updated in NVD database

Technical Details for CVE-2026-47073

Vulnerability Analysis

The vulnerability resides in the WebSocket client logic of src/hackney_ws.erl and surfaces through three independent code paths. The first occurs in read_handshake_response/3, which accumulates received bytes into a growing buffer without any size cap. The per-receive timeout resets on every chunk, so a server that streams bytes without ever sending the \r\n\r\n terminator causes the buffer to grow until memory is exhausted.

The second path lies in parse_payload/9 and parse_active_payload/8. Neither function validates the declared frame payload length against a configurable limit. Because RFC 6455 permits payload lengths up to 2^63-1 bytes, a server can announce a very large frame and dribble bytes to force unbounded buffer growth.

The third path involves the frag_buffer field in the #ws_data{} record. This buffer accumulates continuation frames indefinitely. A server that streams non-final (nofin) fragmented frames without ever emitting a final (fin) frame grows frag_buffer without bound.

Root Cause

The root cause is missing input validation and absent throttling controls in the WebSocket client. None of the three accumulation paths cross-check input length against a configured maximum, and the receive timeout is reset on each chunk rather than measured against total operation duration.

Attack Vector

Exploitation requires only that an attacker control the WebSocket server endpoint that a hackney client connects to. No authentication, special client configuration, or user interaction is required. This makes any application that initiates outbound WebSocket connections to attacker-influenced URLs vulnerable to remote denial of service.

No verified proof-of-concept code is published for this issue. Refer to the GitHub Security Advisory GHSA-q8jg-fgj4-fphf and the CNA advisory for authoritative technical details.

Detection Methods for CVE-2026-47073

Indicators of Compromise

Sustained memory growth in Erlang BEAM processes that initiate outbound WebSocket connections via hackney
Application crashes with system_limit or OOM errors traced to hackney_ws module frames
Long-lived TCP sessions to external WebSocket servers with slow, byte-by-byte ingress patterns

Detection Strategies

Inventory all applications and dependencies that resolve to hackney versions 2.0.0 through 4.0.0 using rebar3 tree, mix deps, or equivalent dependency tooling
Instrument BEAM telemetry to track per-process heap size for processes invoking hackney_ws:start_link/2 or related entry points
Inspect network flows for WebSocket sessions where the server announces large frame payload lengths or never sends final fragmented frames

Monitoring Recommendations

Set alerts on Erlang VM memory metrics (erlang:memory(total)) for sustained linear growth correlated with active WebSocket sessions
Log and review outbound WebSocket destinations and reject connections to untrusted hosts at the egress layer
Track process mailbox and binary heap sizes for hackney-owned processes and trigger investigations on threshold breaches

How to Mitigate CVE-2026-47073

Immediate Actions Required

Upgrade hackney to version 4.0.1 or later in all Erlang and Elixir applications
Audit all transitive dependencies for pinned older hackney versions and force-upgrade them
Restrict outbound WebSocket connections to trusted, validated server endpoints where feasible

Patch Information

The issue is fixed in hackney 4.0.1. The upstream fix introduces bounds on the handshake buffer, validates declared frame payload lengths, and caps fragmented frame accumulation. Review the upstream commit ce0109e2 and the OSV record EEF-CVE-2026-47073 for the canonical fix.

Workarounds

Place a vetted reverse proxy or egress gateway in front of outbound WebSocket traffic to enforce frame size and connection duration limits
Apply per-process memory limits using erlang:process_flag(max_heap_size, ...) on processes that own hackney WebSocket clients
Avoid using hackney WebSocket client code paths against untrusted servers until the upgrade is deployed

bash

# Configuration example: pin hackney to a fixed version in rebar.config
{deps, [
    {hackney, "4.0.1"}
]}.

# Or in mix.exs for Elixir projects
# {:hackney, "~> 4.0.1"}