# CVE-2026-47071: benoitc hackney uncontrolled resource consumption in SOCKS5 TLS upgrade

Source: https://junglewise.ai/threats/cve-2026-47071-benoitc-hackney-uncontrolled-resource-consumption-in-socks5-tls  
Publisher: Junglewise Threat Intelligence, https://junglewise.ai/threats  
Published: 2026-05-25. Updated: 2026-06-26  
License: CC BY 4.0 with a link back

CVE-2026-47071 · Severity: high · CVSS 8.2 · Published 2026-05-25

Hackney, a popular HTTP client library for the Erlang ecosystem, contains a flaw when routing traffic through SOCKS5 proxies. An attacker-controlled or compromised proxy can stall the connection process indefinitely during the secure connection (TLS) setup phase. This can lead to a denial-of-service condition by exhausting system resources, such as memory and available network connections, as the application waits forever for a response that never arrives.

## Quick answers

**Is CVE-2026-47071 exploited in the wild?** No. Junglewise Threat Intelligence has no report of CVE-2026-47071 being exploited in the wild.

**How severe is CVE-2026-47071?** High severity, with a CVSS score of 8.2, published 25 May 2026.

**Which products and versions are affected?** benoitc hackney >= 0.10.0, < 4.0.1.

**Is there a fix for CVE-2026-47071?** A patch was published on 2026-06-26. Junglewise finds every place you run it, drafts the upgrade and applies it once you approve.

**How is CVE-2026-47071 attacked?** It is attacked over the network, in a software library.

**Am I affected by CVE-2026-47071?** Check whether anything you run is named in the advisory. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.

## Technical details

The vulnerability exists in `src/hackney_socks5.erl` where the code performs a post-handshake TLS upgrade. While the SOCKS5 negotiation correctly honors user-supplied timeouts, the subsequent call to `ssl:connect/2` uses the two-argument form which defaults to an infinite timeout. An attacker-controlled SOCKS5 proxy can complete the initial handshake and then stall the TLS exchange (e.g., by not sending a ServerHello). This causes the calling Erlang process to block indefinitely, bypassing `connect_timeout` and `recv_timeout` settings. The issue is fixed in version 4.0.1 by ensuring the timeout value is correctly passed to the SSL connection call.

## Affected products

- benoitc hackney >= 0.10.0, < 4.0.1

## Identifiers

- CVE-2026-47071
- GHSA-gp9c-pm5m-5cxr

## Timeline

- 2026-05-25: disclosed
- 2026-06-26: advisory
- 2026-06-26: patched

## References

- [https://api.github.com/users/PJUllrich](https://api.github.com/users/PJUllrich)
- [https://github.com/PJUllrich](https://github.com/PJUllrich)
- [https://api.github.com/users/PJUllrich/gists%7B/gist_id%7D](https://api.github.com/users/PJUllrich/gists%7B/gist_id%7D)
- [https://api.github.com/users/PJUllrich/repos](https://api.github.com/users/PJUllrich/repos)
- [https://avatars.githubusercontent.com/u/10426523?v=4](https://avatars.githubusercontent.com/u/10426523?v=4)
- [https://api.github.com/users/PJUllrich/events%7B/privacy%7D](https://api.github.com/users/PJUllrich/events%7B/privacy%7D)