Which versions of hackney are affected by EUVD-2026-31685?

Denial of service vulnerability in the benoitc hackney Erlang HTTP client affects versions 0.10.0 through 4.0.0, potentially causing application processes to hang indefinitely when connecting through…. A patch is available.

Is there a public PoC exploit available for EUVD-2026-31685?

Yes, a public proof-of-concept exploit is available for EUVD-2026-31685. Prioritise patching immediately. EPSS: 0.0%.

How to fix or mitigate EUVD-2026-31685?

24 hours: Identify production Erlang applications using benoitc hackney versions 0.10.0-4.0.0; assess exposure for applications using external SOCKS5 or HTTP CONNECT proxies. 7 days: Stage deployment of version 4.0.1 in development and testing environments; validate TLS handshake timeout behavior with proxy configurations. 30 days: Deploy version 4.0.1 to all production instances and confirm timeout enforcement.

hackney EUVD-2026-31685

Q: What is the CVSS score of EUVD-2026-31685?

EUVD-2026-31685 has a CVSS 4.0 base score of 8.2 (High). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:P/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. EPSS exploitation probability: 0.0%.

| CVE-2026-47071 HIGH

Uncontrolled Resource Consumption (CWE-400)

2026-05-25 EEF

GHSA-gp9c-pm5m-5cxr

Denial Of Service Hackney

8.2

CVSS 4.0 · NVD

Severity by source

NVD PRIMARY

8.2 HIGH

CVSS:4.0/AV:N/AC:L/AT:P/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

Primary rating from NVD · only source for this CVE.

CVSS VectorNVD

CVSS:4.0/AV:N/AC:L/AT:P/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

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Lifecycle Timeline

Source Code Evidence Fetched

Jun 08, 2026 - 09:57 vuln.today

Analysis Generated

Jun 08, 2026 - 09:57 vuln.today

CVSS changed

May 26, 2026 - 17:22 NVD

8.2 (HIGH)

CVE Published

May 25, 2026 - 14:00 nvd

UNKNOWN (no severity yet)

DescriptionCVE.org

Uncontrolled Resource Consumption vulnerability in benoitc hackney allows Flooding. The SOCKS5 transport in src/hackney_socks5.erl correctly applies the caller-supplied timeout to the SOCKS5 negotiation phase, but then upgrades the connection to TLS using the two-argument form ssl:connect/2, which defaults to an infinite timeout. The Timeout value is in scope at the call site but is not forwarded. A hostile SOCKS5 proxy that completes the SOCKS5 handshake normally and then goes silent (or sends a partial TLS ServerHello and stalls) will cause the connecting process to block indefinitely, regardless of the connect_timeout or recv_timeout options supplied by the caller.

This issue affects hackney: from 0.10.0 before 4.0.1.

AnalysisAI

Denial of service in benoitc hackney (Erlang HTTP client) versions 0.10.0 through 4.0.0 lets a hostile SOCKS5 or HTTP CONNECT proxy hang the connecting Erlang process indefinitely during the TLS upgrade phase. Because the caller-supplied timeout was not forwarded to ssl:connect/2, which defaults to infinity, recv_timeout and connect_timeout options are silently bypassed. Publicly available exploit code exists per SSVC, EPSS is low (0.04%), and a vendor patch is available in 4.0.1.

Technical ContextAI

hackney is a widely used HTTP client library for Erlang/OTP, frequently pulled in transitively by Elixir HTTP stacks. The bug sits in src/hackney_socks5.erl (and analogously in src/hackney_http_connect.erl) where, after the SOCKS5 or HTTP CONNECT handshake completes, the TCP socket is upgraded to TLS via the two-argument ssl:connect(Socket, SSLOpts) form. Erlang's ssl:connect/2 defaults its timeout to infinity, so the Timeout variable in scope at the call site is never propagated to the TLS handshake. This is a classic CWE-400 Uncontrolled Resource Consumption issue: the resource exhausted is the calling Erlang process and its file descriptor, which are pinned to a stalled handshake despite explicit caller-supplied connect_timeout / recv_timeout values. Affected CPE is cpe:2.3:a:benoitc:hackney:* across all builds from 0.10.0 up to (but not including) 4.0.1.

RemediationAI

Upgrade to hackney 4.0.1, which forwards the caller's Timeout to ssl:connect/3 in both the SOCKS5 and HTTP CONNECT transports (see commit 5ccdab725c561a6f03d05a51f2d0664f98236dae and advisory GHSA-gp9c-pm5m-5cxr at https://github.com/benoitc/hackney/security/advisories/GHSA-gp9c-pm5m-5cxr). If immediate upgrade is not possible, restrict outbound proxy usage to trusted, operator-controlled SOCKS5/HTTPS proxies and reject user-supplied proxy URLs at the application layer - the trade-off is loss of any feature that lets end users choose an arbitrary proxy. As a defense-in-depth control, enforce a per-request supervisor or hard wall-clock kill (e.g., wrap calls in a Task with Task.await/2 timeout, or use a circuit breaker with a max-in-flight budget) so a stalled process cannot accumulate; the side effect is that legitimate slow handshakes will also be cancelled. Do not rely on connect_timeout or recv_timeout alone on vulnerable versions - they are bypassed during the TLS upgrade phase.