CVE-2026-113440 in hackney
Summary
by MITRE • 10/26/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/26/2026
The vulnerability identified in the Hackney HTTP client library represents a critical flaw in how authentication credentials are handled during URL redirections, specifically when the follow_redirect feature is enabled. This security issue stems from an insufficiently protected credential mechanism where the application fails to adequately sanitize or strip sensitive authorization data before reissuing requests to new endpoints. The core technical defect lies within the logic of the hackney:follow_redirect/10 function found in src/hackney.erl, which relies on a helper function called hackney:maybe_strip_auth_on_redirect/3 to determine whether credentials should be removed from outgoing HTTP headers. This stripping process is governed by an overly permissive hostname comparison strategy that only checks if the hostnames of the original request and the redirect target are identical, without considering other critical factors such as network protocols or port numbers.
When a server responds with a redirection status code pointing to a URL on the same hostname but using a different scheme, such as transitioning from HTTPS to HTTP, Hackney incorrectly assumes that the security context remains unchanged due to the matching hostnames. Consequently, it retains and forwards sensitive headers like Authorization containing basic_auth tokens or Cookie headers in cleartext over an unencrypted channel. This behavior exposes user credentials to on-path attackers who can intercept network traffic via man-in-the-middle attacks, leading to a complete compromise of account security and data confidentiality. The vulnerability effectively negates the protections offered by HTTPS when mixed with HTTP redirects on the same domain, creating a significant attack surface for credential theft.
Furthermore, the flaw extends beyond protocol changes to include redirections targeting different ports on the same host. In such scenarios, Hackney forwards credentials to services running on alternative ports that may not be part of the original trusted context or security boundary. This allows an attacker who controls or influences a redirect target on a non-standard port to receive sensitive authentication data intended for the primary service. While the location_trusted option is designed by default to forward credentials to any target regardless of host changes, this specific vulnerability affects cases where such explicit trust was not granted but implicit trust based solely on hostname matching led to unintended credential leakage. The issue impacts versions of Hackney from 2.0.0 up to version 4.9.0, affecting a wide range of applications built with Erlang and Elixir that utilize this library for HTTP communication.
From the perspective of industry standards, this vulnerability aligns closely with CWE-523, which describes unencrypted transmission of sensitive information, particularly when credentials are sent over insecure channels due to improper redirect handling. It also relates to CWE-601, URL redirection to untrusted site, as the application fails to validate that the destination is secure and appropriate for credential forwarding based on more than just hostname equality. In terms of the MITRE ATT&CK framework, this behavior facilitates Credential Access through techniques such as Network Sniffing or Intercepted Authentication Credentials, allowing adversaries to capture login credentials during transit when redirect chains are manipulated by malicious servers or compromised infrastructure.
To mitigate this vulnerability, developers must upgrade Hackney to version 4.9.0 or later where the logic for stripping authentication headers has been corrected to account for scheme and port differences in addition to hostname matching. Applications relying on older versions should implement custom middleware or wrapper functions that explicitly check if a redirect involves a change from HTTPS to HTTP or a different port, ensuring that Authorization and Cookie headers are stripped before reissuing the request unless explicit trust is configured via location_trusted. Additionally, security teams should audit their use of follow_redirect settings and consider disabling automatic redirections for sensitive endpoints where manual control over credential handling is required. Regular updates to third-party dependencies and rigorous testing of redirect scenarios in staging environments are essential practices to prevent similar exposure of authentication data in production systems.