The vulnerability in benoitc hackney arises because the SOCKS5 transport implementation applies the caller-supplied timeout only during the SOCKS5 handshake but not during the TLS upgrade that follows. The TLS connection uses ssl:connect/2 with an infinite timeout by default, ignoring the intended timeout values. A hostile SOCKS5 proxy can exploit this by completing the SOCKS5 handshake and then stalling during the TLS ServerHello phase, causing the client process to block indefinitely. This results in uncontrolled resource consumption (CWE-400) and potential denial of service. The issue affects hackney versions from 0.10.0 up to but not including 4.0.1.

An attacker controlling a SOCKS5 proxy can cause the hackney client to block indefinitely during TLS negotiation, leading to resource exhaustion on the client side. This can result in denial of service conditions for applications relying on hackney for HTTP connections via SOCKS5 proxies. There is no indication of privilege escalation, data disclosure, or code execution from this vulnerability.

Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. No official fix or patch information is provided in the available data. Until a patch is available, users should consider avoiding use of untrusted SOCKS5 proxies or implement external timeout controls at the application or network level to mitigate indefinite blocking during TLS negotiation.