hackney CVE-2026-115700

Exploitation requires a consuming application that (1) builds an SSRF host allowlist/denylist using uri_string:parse/1 and inet:parse_address/1, and (2) passes the attacker-influenced URL (or a followed redirect Location) to hackney versions 4.0.1 up to but not including 4.9.0. The attacker must supply the host in one of two exact spellings: a percent-encoded bracketed IPv6 literal (e.g. %5B%3A%3Affff%3A127%2E0%2E0%2E1%5D decoding to [::ffff:127.0.0.1]) or an IP literal with a trailing dot (e.g. 127.0.0.1.). Limiting factors: unencoded IPv6 literals and domain names with a trailing dot are NOT affected; the bypass is meaningless unless the application relies on the vulnerable validation pattern; and applications on 4.9.0 or later are protected. No authentication is indicated by the vector (PR:N), and no user interaction is required (UI:N).

This is a genuine but moderate-priority SSRF (CVSS 4.0 base 6.9, Medium; CWE-436 Interpretation Conflict). The decision signals are consistent and point to urgency below the top tier: the vuln.today priority label is 'this_month', not act_now/emergency; there is no CISA KEV listing and no EPSS score supplied; and no public exploit is identified. A vendor patch (4.9.0) is confirmed available. Realistic risk is gated heavily by the exploitation pre-condition: the flaw only matters to applications that build an SSRF allowlist/denylist using uri_string:parse/1 plus inet:parse_address/1 and then pass the host to hackney - exactly the defensive pattern CVE-2026-47076 was meant to protect, which this bypasses. Where that pattern is used, impact is real (internal/loopback reachability, confidentiality of internal services). A notable signal conflict: the supplied CVSS 4.0 vector uses AV:L (local), whereas SSRF driven by an attacker-supplied URL or redirect Location is typically network-reachable (AV:N) when the consuming app accepts remote input - the effective vector depends on how the downstream application sources the URL, so verify against your own data flow rather than assuming local-only access. No integrity or availability impact is indicated by the metrics (VI:N/VA:N).

An application uses hackney with an SSRF allowlist that validates the destination host via uri_string:parse/1 and inet:parse_address/1 before fetching a user-supplied URL. The attacker submits a host such as %5B%3A%3Affff%3A127%2E0%2E0%2E1%5D (decoding to [::ffff:127.0.0.1]) or 127.0.0.1. with a trailing dot; the allowlist does not recognize these as IP literals and permits them, but hackney's connect path strips the brackets / ignores the trailing dot and connects to the loopback/internal address anyway. No public exploit code is identified at time of analysis; the same bypass applies to a redirect Location when redirects are followed.