Is there a public PoC exploit available for CVE-2026-47070?

Yes, a public proof-of-concept exploit is available for CVE-2026-47070. Prioritise patching immediately. EPSS: 0.0%.

Is there a patch available for CVE-2026-47070?

Yes, a patch is available for CVE-2026-47070. Update the affected software to the latest version immediately.

hackney CVE-2026-47070

Q: What is the CVSS score of CVE-2026-47070?

CVE-2026-47070 has a CVSS 4.0 base score of 6.0 (Medium). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.0%.

EUVD-2026-31692 MEDIUM

URL Redirection to Untrusted Site (Open Redirect) (CWE-601)

2026-05-25 EEF

GHSA-h73q-4w9q-82h4

Information Disclosure Open Redirect Hackney

6.0

CVSS 4.0 · NVD

Severity by source

NVD PRIMARY

6.0 MEDIUM

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Primary rating from NVD · only source for this CVE.

CVSS VectorNVD

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

Scope

Lifecycle Timeline

Source Code Evidence Fetched

Jun 08, 2026 - 12:15 vuln.today

Analysis Generated

Jun 08, 2026 - 12:15 vuln.today

CVSS changed

May 26, 2026 - 17:22 NVD

6.0 (MEDIUM)

CVE Published

May 25, 2026 - 14:00 nvd

UNKNOWN (no severity yet)

DescriptionCVE.org

Sensitive Data Exposure vulnerability in benoitc hackney allows Retrieve Embedded Sensitive Data. The HTTP/3 redirect handler in src/hackney_h3.erl passes the original request headers unchanged to the redirect target without performing any cross-origin check. When a client issues an HTTP/3 request with follow_redirect enabled and includes Authorization or Cookie headers, a server responding with a 3xx redirect to a different host will cause the client to forward those credentials verbatim to the new origin.

The main hackney.erl module has maybe_strip_auth_on_redirect/2 (guarded by the location_trusted option) to address CVE-2018-1000007, but hackney_h3.erl is missing this protection entirely.

This issue affects hackney: from 3.1.1 before 4.0.1.

AnalysisAI

Credential leakage in the hackney Erlang HTTP client library (versions 3.1.1 through before 4.0.1) allows a malicious or compromised redirect target to capture Authorization, Cookie, and Proxy-Authorization headers forwarded verbatim by the HTTP/3 redirect handler. The hackney_h3.erl module, introduced for HTTP/3 support, omitted the cross-origin credential-stripping logic (maybe_strip_auth_on_redirect/2) that was added to the main hackney.erl module following CVE-2018-1000007, creating a feature-parity gap exploitable when clients use follow_redirect with HTTP/3 and credential headers. No active exploitation is confirmed (not in CISA KEV), but SSVC assessment confirms a proof-of-concept exists; EPSS is low at 0.04% (13th percentile), consistent with targeted rather than opportunistic exploitation.

Technical ContextAI

hackney is a widely used Erlang HTTP client library maintained by benoitc, identified by CPE cpe:2.3:a:benoitc:hackney:*:*:*:*:*:*:*:*. The vulnerability resides in src/hackney_h3.erl, the HTTP/3-specific transport module. CWE-601 (URL Redirection to Untrusted Site) captures the root cause: when handle_redirect processes a 3xx response, it passes the original Headers list directly to do_request_with_redirect without invoking any origin comparison. The main module hackney.erl has carried the same_origin/location_trusted guard since CVE-2018-1000007, but hackney_h3.erl was written without porting that protection. The CVSS 4.0 vector encodes AT:P (Attack Requirements: Present), reflecting that exploitation requires the specific combination of HTTP/3 transport, follow_redirect enabled, and credential headers being present in the outbound request - conditions common in server-to-server API clients but not universal.

RemediationAI

Vendor-released patch: upgrade to hackney 4.0.1 or later. The fix is confirmed in commit c58d5b50bade146360b85caf3dc8065807b08246 (https://github.com/benoitc/hackney/commit/c58d5b50bade146360b85caf3dc8065807b08246), which adds maybe_strip_redirect_headers/4 to hackney_h3.erl performing a same_origin/3 check (comparing scheme, lowercased host, and port) before forwarding headers, and drops Authorization, Cookie, and Proxy-Authorization on cross-origin redirects unless the caller sets location_trusted: true. If an immediate upgrade is not possible, the most effective compensating control is to disable follow_redirect in any HTTP/3 client calls that include credential headers, then implement manual redirect handling with explicit credential stripping before following cross-origin locations - this eliminates the vulnerable code path entirely at the cost of added application logic. Alternatively, restricting outbound HTTP/3 requests to trusted, internally controlled hosts via network policy removes the ability of an attacker-controlled server to issue redirect responses. Setting location_trusted: true is NOT a mitigation - it opts into the vulnerable behavior intentionally and should only be used when the redirect target is fully trusted.