CVE-2026-47070: Benoitc Hackney Information Disclosure Bug

CVE-2026-47070 Overview

CVE-2026-47070 is a sensitive data exposure vulnerability in benoitc/hackney, an HTTP client library for Erlang. The HTTP/3 redirect handler in src/hackney_h3.erl forwards original request headers unchanged to redirect targets without performing a cross-origin check. When a client issues an HTTP/3 request with follow_redirect enabled and includes Authorization or Cookie headers, a 3xx redirect to a different host causes those credentials to be forwarded verbatim to the new origin. The flaw affects hackney versions from 3.1.1 before 4.0.1 and is classified under [CWE-601] (URL Redirection to Untrusted Site).

Critical Impact

Attackers controlling a redirect target can harvest authentication credentials and session cookies from HTTP/3 clients using follow_redirect, enabling account takeover and session hijacking.

Affected Products

• benoitc hackney 3.1.1 through 4.0.0
• Erlang applications depending on hackney for HTTP/3 client functionality
• Downstream libraries that wrap hackney with follow_redirect enabled

Discovery Timeline

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

Technical Details for CVE-2026-47070

Vulnerability Analysis

The vulnerability stems from a missing security control in the HTTP/3 redirect path of hackney. The main hackney.erl module implements maybe_strip_auth_on_redirect/2, guarded by the location_trusted option. This function was introduced to remediate CVE-2018-1000007 by stripping sensitive headers when redirects cross origin boundaries. The HTTP/3 handler in src/hackney_h3.erl does not call this routine and does not perform any equivalent cross-origin check.

As a result, an HTTP/3 request issued with follow_redirect enabled treats every redirect target as trusted. The client transmits the original Authorization header, bearer tokens, and Cookie values to whatever host the upstream server names in its 3xx Location response. An attacker who controls or compromises a redirecting endpoint can capture these credentials.

Root Cause

The HTTP/3 code path was implemented without parity with the HTTP/1.x and HTTP/2 redirect logic. Specifically, hackney_h3.erl lacks the cross-origin credential stripping that hackney.erl applies through maybe_strip_auth_on_redirect/2. This is a security regression introduced when HTTP/3 support was added in version 3.1.1.

Attack Vector

Exploitation requires a target application to issue an HTTP/3 request through hackney with follow_redirect set to true while attaching credentials. The attacker must either control a server that the client contacts, compromise a legitimate server, or perform a man-in-the-middle attack capable of injecting a 3xx response. Upon receiving the redirect, the hackney client connects to the attacker-specified host and replays the original Authorization and Cookie headers, exposing them to the attacker. The fix is implemented in commit c58d5b50bade146360b85caf3dc8065807b08246.

Detection Methods for CVE-2026-47070

Indicators of Compromise

• Outbound HTTP/3 (QUIC over UDP/443) connections from application servers to unexpected external hosts following a 3xx response
• Authentication tokens or session cookies appearing in server access logs of untrusted third-party domains
• Unexpected authentication events originating from third-party IP ranges shortly after legitimate API calls

Detection Strategies

• Inventory Erlang and Elixir applications and identify dependencies on hackney versions between 3.1.1 and 4.0.0 using rebar3 tree or mix deps
• Inspect application code for usage of follow_redirect together with HTTP/3 transport and Authorization or Cookie headers
• Monitor egress proxy logs for HTTP/3 redirects that cross origin boundaries from hosts running affected applications

Monitoring Recommendations

• Alert on credential reuse from non-corporate IP addresses immediately after outbound HTTP/3 traffic from application hosts
• Capture and review QUIC connection metadata at the network perimeter to flag redirect chains terminating at untrusted domains
• Correlate Software Composition Analysis (SCA) findings for vulnerable hackney versions against runtime telemetry from application servers

How to Mitigate CVE-2026-47070

Immediate Actions Required

• Upgrade hackney to version 4.0.1 or later in all Erlang and Elixir projects
• Audit all call sites that combine follow_redirect => true with credentialed HTTP/3 requests and disable automatic redirect following until patched
• Rotate any bearer tokens, API keys, or session cookies that may have transited HTTP/3 redirects on affected versions

Patch Information

The fix is available in hackney 4.0.1. The remediation commit adds cross-origin credential stripping to the HTTP/3 redirect handler, bringing hackney_h3.erl to parity with hackney.erl. Review the GitHub Security Advisory GHSA-h73q-4w9q-82h4, the CNA advisory from the Erlang Ecosystem Foundation, and the upstream patch commit for full technical context.

Workarounds

• Disable follow_redirect for any HTTP/3 request that carries Authorization or Cookie headers and handle 3xx responses manually with explicit origin checks
• Avoid the HTTP/3 transport in hackney until the upgrade is deployed, falling back to HTTP/1.1 or HTTP/2 which apply the existing maybe_strip_auth_on_redirect/2 protection
• Restrict outbound egress from application hosts so HTTP/3 redirects cannot reach attacker-controlled destinations

# Configuration example: pin hackney to a patched version in rebar.config
{deps, [
    {hackney, "4.0.1"}
]}.

# Or in mix.exs for Elixir projects
defp deps do
  [
    {:hackney, "~> 4.0.1"}
  ]
end