hackney EUVD-2026-109835

Requires the application to call hackney with follow_redirect enabled (an opt-in option, not the default) AND to attach credentials via the basic_auth and/or cookie options on the request. The attacker must be able to make a server on the target host return a same-host redirect that either downgrades the scheme (https→http) - exploitable by an on-path attacker who then reads the cleartext Authorization/Cookie headers - or changes the port, handing the credentials to a different service on the same host. Limiting factors: non-default follow_redirect configuration, credentials must actually be present on the request, the host must be influenced to emit the downgrading/port-changing redirect, and the cleartext-read variant additionally needs on-path network position. The location_trusted mode forwards credentials to any target by design and is out of scope. Affects hackney 2.0.0 up to (not including) 4.9.0.

This is a medium-severity credential-exposure flaw (CVSS 4.0 base 6.0; VC:H with VI/VA:N - confidentiality-only impact). The CVSS 4.0 vector shows AV:N but materially qualifies it: AT:P (a specific attack requirement must be met) and UI:P (passive interaction by the credential-bearing client). PR:N indicates the attacker needs no credentials of their own against the hackney client. No EPSS score and no KEV listing were supplied, so there is no active-exploitation signal: exploitation status is 'no public exploit identified at time of analysis' (the provided references are the vendor PR, advisory, and patch commits - fix artifacts, not a weaponized PoC). The vuln.today Decision label is 'this_month', consistent with a real-but-not-emergency priority: this is a genuine credential-leak bug, not merely a high-CVSS-but-low-real-risk issue, but it is bounded by several preconditions (follow_redirect enabled, credentials actually present on the request, and an attacker able to influence a same-host redirect and/or hold an on-path position). The confidentiality impact is high because basic_auth and cookie credentials can be disclosed, but there is no integrity or availability impact. Net: patch within normal maintenance cadence (this month), treat as elevated for any service that uses hackney with follow_redirect against hosts that can be influenced to downgrade scheme or change port.

An application using hackney with follow_redirect enabled issues an authenticated request (basic_auth and/or cookie) to a host; a malicious or compromised redirecting server on that host responds with a 30x redirect to the same hostname but a different scheme (https→http) or a different port. Because the pre-4.9.0 code compared only the hostname, hackney reissues the request with the Authorization and Cookie headers intact - an on-path attacker then reads them in cleartext over the http downgrade, or a different service listening on the other port receives them directly. No public exploit identified at time of analysis.