Know every vulnerabilitybefore it knows you.
DevGuard continuously monitors your dependencies and alerts you when CVEs like this one affect your stack — with real-time threat intelligence built for developers.
EEF-CVE-2026-113440
Summary
Insufficiently Protected Credentials vulnerability in hackney in benoitc hackney allows a redirecting server to obtain the basic_auth and cookie credentials of a request via a same-host redirect to another scheme or port. With follow_redirect enabled, hackney:follow_redirect/10 in src/hackney.erl reissues the request to the Location target after hackney:maybe_strip_auth_on_redirect/3, which compared only the hostname of the current and the redirect URL. A redirect from https to http on the same host resent the Authorization and Cookie headers in cleartext, where an on-path attacker can read them, and a redirect to another port on the same host handed them to a different service. location_trusted forwards credentials to any target by design and is unchanged.
This issue affects hackney: from 2.0.0 before 4.9.0.
Details
1. Redirect handling. With follow_redirect set, hackney:request/5 hands a 3xx response to hackney:follow_redirect/10 in src/hackney.erl, which resolves the Location header against the current URL and calls hackney:request/5 again with the caller's options and an empty header list. HTTP/1.1 and HTTP/2 share this path.
2. Host-only comparison. Before the new request, hackney:maybe_strip_auth_on_redirect/3 removes the basic_auth and cookie options when the redirect leaves the current host, unless location_trusted is set. It compared #hackney_url.host of the two URLs.
3. Consequence. A redirect that keeps the hostname but changes the scheme or the port passes the check, so the new request carries the same Authorization and Cookie headers. From https to http they travel in cleartext; to another port they reach a different service on the same host.
Impact
A server that answers a credentialed request with a same-host redirect to plain HTTP exposes the client's Authorization and Cookie headers to anyone on the network path, and a redirect to another port delivers them to whatever service listens there. The captured values can be replayed against the original origin.
Workarounds
Disable follow_redirect and handle the Location header in the application, or pass the credentials as explicit Authorization and Cookie request headers instead of the basic_auth and cookie options. hackney:follow_redirect/10 issues the redirected request with an empty header list, so explicit headers reach the first server only.
Configurations
The request is made with follow_redirect enabled and the basic_auth or cookie option set, over HTTP/1.1 or HTTP/2, without location_trusted. Credentials passed as explicit request headers are not forwarded on redirects and are not affected.
Upload your own SBOM in CycloneDX 1.6 or higher (JSON) directly here to check your vulnerabilities.
Drag and drop some file here, or click to select
The vulnerability can be exploited over the network without needing physical access. It is easy for an attacker to exploit this vulnerability. An attacker does not need any special privileges or access rights.
Limited exploitation activity has been observed. Close monitoring and planned remediation are recommended.
The exploit probability is very low. The vulnerability is unlikely to be exploited in the next 30 days.
We did not find any exploit available. Neither in GitHub repositories nor in the Exploit-Database.
Browse More
Continuously monitor your dependencies and get alerted when vulnerabilities like this one affect your stack.
Checkout DevGuard