CVE-2026-47076: Benoitc Hackney SSRF Vulnerability

CVE-2026-47076 Overview

CVE-2026-47076 is a Server-Side Request Forgery (SSRF) vulnerability in benoitc/hackney, a widely used HTTP client library for Erlang. The flaw stems from an interpretation conflict [CWE-436] between hackney's URL normalizer and Erlang/OTP's URI parsing functions. An attacker can supply a percent-encoded host such as http://%31%32%37%2E%30%2E%30%2E%31/ that bypasses an application's allowlist validator, then gets decoded by hackney to 127.0.0.1 before the TCP connection opens. The issue affects hackney versions from 0.13.0 before 4.0.1.

Critical Impact
Attackers can reach loopback services, RFC1918 networks, and cloud instance metadata endpoints such as 169.254.169.254, exposing credentials and internal admin interfaces.

Affected Products

benoitc hackney 0.13.0 through 4.0.0
Erlang applications using hackney:request/5 with binary or list URLs
Downstream libraries wrapping hackney for HTTP fetching

Discovery Timeline

2026-05-25 - CVE-2026-47076 published to NVD
2026-05-27 - Last updated in NVD database

Technical Details for CVE-2026-47076

Vulnerability Analysis

The vulnerability is an interpretation conflict between two URL parsing layers. When an application validates a URL against an allowlist, it typically uses uri_string:parse/1 and inet:parse_address/1 from Erlang/OTP. Neither function decodes percent-escapes in the host component. A host string like %31%32%37%2E%30%2E%30%2E%31 is therefore not recognized as an IP address and passes allowlist checks that block loopback or private ranges.

After validation, the application passes the URL to hackney:request/5, which unconditionally calls hackney_url:normalize/2. This normalizer URL-decodes the host inside the #hackney_url{} record, transforming the encoded string into 127.0.0.1. The HTTP request then opens a TCP connection to the decoded address.

Root Cause

The root cause is inconsistent host handling between hackney and OTP. hackney_url:normalize/2 performs percent-decoding on the host after parsing, while OTP parsers leave the encoded form intact. The normalize step is mandatory in hackney:request/5 with no opt-out flag, so every binary or list URL submitted to hackney is subject to this transformation.

Attack Vector

An attacker who controls a URL submitted to an application that fetches remote resources through hackney can target any internal host. The technique reaches cloud metadata services at 169.254.169.254 to steal IAM credentials, RFC1918 networks for lateral discovery, and admin interfaces bound to localhost. Encoding variations such as mixed case, overlong UTF-8, or partial encoding can defeat naive string-based filters that attempt to block the literal sequence. Refer to the GitHub Security Advisory GHSA-pj7v-xfvx-wmjq for additional technical detail.

Detection Methods for CVE-2026-47076

Indicators of Compromise

Outbound HTTP requests from application hosts to 127.0.0.1, 169.254.169.254, or RFC1918 destinations originating from the hackney client process.
Application logs containing inbound URLs with percent-encoded host octets such as %31, %32, %2E in the authority component.
Unexpected access patterns to cloud instance metadata endpoints from services that normally do not query them.

Detection Strategies

Inventory Erlang and Elixir dependencies for hackney versions older than 4.0.1 using rebar3 tree or mix deps.
Add WAF or reverse proxy rules that decode and re-validate URL parameters before they reach application code.
Inspect runtime egress telemetry for connections from application workloads to link-local and loopback IP ranges.

Monitoring Recommendations

Log every URL passed to hackney:request/5 along with its post-normalization host for offline review.
Alert on any outbound connection to 169.254.169.254 from workloads that do not legitimately query metadata services.
Correlate fetch-from-URL feature usage with destination IP to surface SSRF attempts in real time.

How to Mitigate CVE-2026-47076

Immediate Actions Required

Upgrade benoitc/hackney to version 4.0.1 or later across all Erlang and Elixir projects.
Audit application code paths that accept user-supplied URLs and forward them to hackney.
Restrict egress from application hosts to only the destinations they require, denying loopback and metadata IPs by default.

Patch Information

The fix is committed in hackney commit 452620a and ships in version 4.0.1. The patched normalizer aligns host handling with OTP's parser behavior so allowlist validators and the connection layer agree on the resolved host. See the CNA CVE-2026-47076 Report and the OSV record EEF-CVE-2026-47076 for distribution details.

Workarounds

Decode percent-escapes in the host component before invoking any allowlist check, then re-parse with inet:parse_address/1 to detect IP literals.
Resolve the hostname and validate the resulting IP against deny lists for loopback, link-local, and RFC1918 ranges prior to issuing the request.
Require IMDSv2 with session tokens on AWS workloads to blunt metadata theft if SSRF succeeds.

bash

# Configuration example - upgrade hackney in a rebar3 project
rebar3 upgrade hackney
# Or in mix.exs for Elixir projects
# {:hackney, "~> 4.0.1"}
mix deps.update hackney