CVE-2026-47071: Benoitc Hackney DOS Vulnerability

CVE-2026-47071 Overview

CVE-2026-47071 is an uncontrolled resource consumption vulnerability [CWE-400] affecting the hackney HTTP client library for Erlang, maintained by benoitc. The flaw resides in the SOCKS5 transport implementation (src/hackney_socks5.erl), where the caller-supplied timeout is correctly applied to the SOCKS5 negotiation phase but is not forwarded to the subsequent TLS upgrade. The connection upgrade calls ssl:connect/2, which defaults to an infinite timeout. A hostile SOCKS5 proxy can complete the SOCKS5 handshake normally and then stall, causing the connecting Erlang process to block indefinitely. The vulnerability affects hackney versions from 0.10.0 before 4.0.1.

Critical Impact
A malicious or compromised SOCKS5 proxy can force client processes to hang indefinitely, bypassing connect_timeout and recv_timeout options and exhausting process, socket, and memory resources on the calling host.

Affected Products

benoitc hackney versions 0.10.0 through 4.0.0
Erlang and Elixir applications using hackney as an HTTP client through SOCKS5 proxies
Downstream libraries depending on hackney for HTTPS-over-SOCKS5 transport

Discovery Timeline

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

Technical Details for CVE-2026-47071

Vulnerability Analysis

The hackney library provides an HTTP client for Erlang applications, including support for tunneling HTTPS traffic through SOCKS5 proxies. The SOCKS5 transport module hackney_socks5.erl performs a two-stage connection: first the SOCKS5 negotiation with the proxy, then a TLS handshake with the upstream destination. The first stage correctly honors the caller's Timeout value, but the second stage invokes ssl:connect/2 without passing that timeout. Because ssl:connect/2 defaults to an infinite timeout, a silent or partial TLS response from the proxy causes the calling process to block indefinitely.

Root Cause

The root cause is missing timeout propagation between two related I/O operations. The Timeout variable is in lexical scope at the ssl:connect/2 call site but is not forwarded. The fix replaces the two-argument call with ssl:connect/3, passing the caller-supplied timeout so TLS negotiation observes the same upper bound as the SOCKS5 phase. Details are available in the hackney commit 5ccdab7 and the GHSA-gp9c-pm5m-5cxr advisory.

Attack Vector

An attacker controlling or impersonating a SOCKS5 proxy completes the SOCKS5 handshake correctly, then either goes silent or sends a partial TLS ServerHello and stalls. The client process invokes ssl:connect/2 and waits forever for the handshake to complete. Repeated connections accumulate stalled Erlang processes, ports, and TLS state, leading to resource exhaustion on the client. The attack is network-reachable and requires no authentication, but does require the victim to route HTTPS traffic through an attacker-influenced SOCKS5 proxy.

Detection Methods for CVE-2026-47071

Indicators of Compromise

Long-lived Erlang processes blocked in ssl:connect/2 with stack frames inside hackney_socks5
Growing counts of open TCP sockets to a SOCKS5 proxy endpoint without corresponding upstream TLS completion
Application timeouts or queue backpressure on workers performing outbound HTTPS via SOCKS5

Detection Strategies

Inventory dependencies with mix deps or rebar3 tree and flag hackney versions below 4.0.1
Instrument hackney callers with wall-clock measurements around requests and alert when durations exceed the configured connect_timeout
Use Erlang observer or recon to enumerate processes stuck in ssl_connection for longer than expected

Monitoring Recommendations

Track outbound connection counts and TLS handshake completion rates per SOCKS5 proxy destination
Alert on sustained increases in the Erlang VM process count or port count on hosts running hackney-based services
Log and review any SOCKS5 proxy configurations that point to externally controlled or recently changed endpoints

How to Mitigate CVE-2026-47071

Immediate Actions Required

Upgrade hackney to version 4.0.1 or later across all Erlang and Elixir projects
Audit application configuration for SOCKS5 proxy usage and restrict proxies to trusted, authenticated endpoints
Restart long-running services after upgrading to clear any processes already stalled in ssl:connect/2

Patch Information

The fix is included in hackney4.0.1. The upstream patch forwards the caller-supplied timeout to the TLS upgrade by switching to ssl:connect/3. Review the upstream commit, the GitHub Security Advisory GHSA-gp9c-pm5m-5cxr, the Erlang Ecosystem Foundation CNA record, and the OSV entry EEF-CVE-2026-47071.

Workarounds

Avoid the SOCKS5 transport in hackney until the upgrade is applied; route HTTPS traffic directly or through a vetted HTTP proxy
Wrap hackney calls in an external timeout, for example using Task.async with Task.yield/2 and Task.shutdown/2 in Elixir, to bound stalled requests
Restrict outbound network egress so that hackney-based services can only reach known, trusted SOCKS5 proxies

bash

# Configuration example: pin hackney to the patched version in mix.exs
# {:hackney, "~> 4.0.1"}
mix deps.update hackney
mix deps.get
mix deps.compile hackney