PatchSiren

PatchSiren cyber security CVE debrief

CVE-2026-47076 benoitc CVE debrief

A Server-Side Request Forgery (SSRF) vulnerability exists in the hackney HTTP client library for Erlang/Elixir. The root cause is an interpretation conflict between how hackney normalizes URLs versus how standard OTP functions parse them. Specifically, hackney_url:normalize/2 URL-decodes the host component after parsing, while uri_string:parse/1 and inet:parse_address/1 do not decode percent-escapes in the host. This allows an attacker to bypass allowlist-based SSRF protections by encoding restricted hosts (e.g., 127.0.0.1, 169.254.169.254) using percent-encoding. A validator checking the raw parsed host sees %31%32%37%2E%30%2E%30%2E%31 (not matching IP patterns), passes the check, and then hackney decodes this to 127.0.0.1 and establishes a TCP connection to the loopback interface. The vulnerability affects all requests using binary or list URLs since hackney:request/5 unconditionally calls hackney_url:normalize/2 with no opt-out mechanism. Attack vectors include accessing cloud instance metadata services, RFC1918 private networks, and administrative interfaces bound to localhost. The issue was introduced in version 0.13.0 and was patched in version 4.0.1.

Vendor
benoitc
Product
hackney
CVSS
MEDIUM 6.9
CISA KEV
Not listed in stored evidence
Original CVE published
2026-05-25
Original CVE updated
2026-05-27
Advisory published
2026-05-25
Advisory updated
2026-05-27

Who should care

Organizations running Erlang/Elixir applications using hackney for HTTP requests, particularly those with SSRF protections based on URL parsing; cloud-native deployments where instance metadata access must be restricted; security teams responsible for reviewing allowlist-based input validation logic

Technical summary

The hackney HTTP client library contains an interpretation conflict vulnerability (CWE-436) leading to Server-Side Request Forgery (CWE-918). The hackney_url:normalize/2 function performs URL decoding on the host component after initial parsing, while OTP's uri_string:parse/1 and inet:parse_address/1 do not. This discrepancy allows percent-encoded representations of restricted hosts to pass validation checks that operate on the pre-decoded host string. Since hackney:request/5 always invokes normalization without opt-out, all URL-based requests are affected. The vulnerability enables access to localhost, link-local addresses (169.254.169.254), and private RFC1918 networks, posing significant risk in cloud and containerized environments where metadata services and administrative interfaces may be exposed.

Defensive priority

high

Recommended defensive actions

  • Upgrade hackney to version 4.0.1 or later
  • Audit application code for any custom URL validation that relies on uri_string:parse/1 or inet:parse_address/1 without additional normalization
  • Implement defense-in-depth by validating resolved IP addresses after connection establishment, not just parsed URL components
  • Consider network-level egress filtering to restrict outbound connections to sensitive IP ranges (localhost, link-local, metadata services)
  • Review and test any allowlist-based SSRF protections for susceptibility to encoding-based bypasses

Evidence notes

The vulnerability description and affected version range (0.13.0 before 4.0.1) are drawn from the official CVE record. The CVSS 4.0 vector indicates local attack vector with high confidentiality impact on the vulnerable component and high confidentiality impact on the subsequent system. The fix commit and GitHub Security Advisory are referenced in source metadata.

Official resources

2026-05-25