The vulnerability in benoitc hackney stems from inconsistent URL host decoding between hackney and OTP libraries. hackney_url:normalize/2 decodes percent-encoded characters in the host 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 an allowlist validator sees a percent-encoded host string (e.g., %31%32%37%2E%30%2E%30%2E%31) and incorrectly allows it, while hackney subsequently decodes it to a sensitive IP address like 127.0.0.1 and makes a TCP connection. This behavior enables SSRF attacks targeting internal network resources, including localhost, RFC1918 addresses, and cloud instance metadata services (169.254.169.254). Every hackney request using a binary or list URL is affected due to the unconditional call to hackney_url:normalize/2. The vulnerability is present in hackney versions from 0.13.0 up to but not including 4.0.1.

An attacker can exploit this vulnerability to perform SSRF attacks by bypassing host allowlist checks through percent-encoding. This can lead to unauthorized access to internal network resources such as localhost services, private RFC1918 networks, and cloud instance metadata endpoints. The impact is limited to the ability to make unauthorized TCP connections to internal addresses from applications using vulnerable hackney versions. There is no indication of privilege escalation or direct code execution from the provided data.

Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. No official patch or remediation level is indicated in the provided data. Until a fix is available, users should consider implementing additional validation on URLs before passing them to hackney, specifically normalizing and validating host components consistently to prevent percent-encoding bypass. Monitoring vendor channels for updates and upgrading to hackney versions 4.0.1 or later once released is recommended.