The vulnerability in benoitc hackney stems from inconsistent URL parsing behavior: hackney_url:normalize/2 decodes percent-encoded characters in the host portion of a URL after parsing, whereas OTP's uri_string:parse/1 and inet:parse_address/1 do not decode these percent-escapes. This leads to a scenario where allowlist validators see the encoded host (e.g., %31%32%37%2E%30%2E%30%2E%31) and consider it safe, but hackney subsequently decodes it to an IP address (127.0.0.1) and makes a TCP connection to that address. Because hackney:request/5 always normalizes URLs this way without an opt-out, all requests using binary or list URLs are affected. This enables SSRF attacks targeting internal networks, including localhost and cloud instance metadata services. The vulnerability affects hackney versions from 0.13.0 up to but not including 4.0.1. No patch or official remediation level is currently documented.

An attacker can exploit this vulnerability to bypass allowlist checks by encoding IP addresses in URLs, causing hackney to connect to internal or restricted network addresses such as localhost (127.0.0.1), cloud instance metadata services (169.254.169.254), or RFC1918 private networks. This SSRF can lead to unauthorized access to internal resources or sensitive information. The CVSS 4.0 score is 6.9 (medium severity), reflecting the local attack vector with low complexity and no privileges required, but with high impact on confidentiality.

Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Until an official fix is available, users should consider implementing additional validation on URLs before passing them to hackney, avoiding untrusted input, or restricting network access from applications using affected hackney versions. Monitor vendor channels for updates and patches addressing this issue.