CVE-2026-112880 in Hackney
Summary
by MITRE • 10/26/2026
Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting') vulnerability in hackney_http_connect in benoitc hackney allows HTTP Request Splitting via the value a proxy_auth_fun callback returns. After a 407 response from an HTTP CONNECT proxy, hackney_http_connect:handle_proxy_auth/11 calls the caller's proxy_auth_fun with the status code and the response headers and writes the returned binary into the Proxy-Authorization line of the CONNECT retry without checking it. A CR, LF or NUL byte in that value adds header lines to the request sent to the proxy.
The value is attacker-influenced when the callback derives it from untrusted data, for example from the proxy's challenge headers. Other caller-supplied values on the CONNECT path, such as the target host and the request headers, were already checked for control bytes.
This issue affects hackney: from 2.0.0 before 4.9.0.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/26/2026
The vulnerability identified in the benoic/hackney library constitutes a critical HTTP Request Splitting flaw within the http_connect module, specifically affecting versions ranging from 2.0.0 up to but not including 4.9.0. This security defect arises from an improper neutralization of Carriage Return and Line Feed sequences within HTTP headers, allowing attackers to inject arbitrary header lines into outgoing requests. The core technical failure occurs during the authentication handshake with a proxy server that requires credentials via Proxy-Authorization. When hackney_http_connect receives a 407 Proxy Authentication Required response from an upstream proxy, it invokes the user-supplied callback function named proxy_auth_fun. This callback is designed to return the necessary authorization credentials as a binary string. However, the library fails to validate this returned value for control characters before embedding it directly into the HTTP request line. Consequently, if the callback returns data containing carriage return or newline bytes, these are interpreted by the underlying TCP stack and subsequent proxy servers as delimiters between headers rather than literal content within the Proxy-Authorization field.
This lack of input validation enables an attacker to perform HTTP Request Splitting attacks when they can influence the output of the proxy_auth_fun callback. The risk is most acute when the callback derives its return value from untrusted sources, such as parsing challenge headers sent by a malicious or compromised proxy server. By injecting CRLF sequences into the returned binary, an adversary can effectively terminate the legitimate Proxy-Authorization header and append new, arbitrary HTTP headers to the request. This capability allows for sophisticated attacks including cache poisoning, where injected headers manipulate caching behavior of downstream intermediaries; session hijacking, if cookies or authentication tokens are manipulated via added headers; and cross-site scripting if the split request leads to reflected content in a victim's browser context through subsequent responses that reflect the attacker-controlled data. The vulnerability is particularly dangerous because it bypasses existing safeguards present elsewhere in the CONNECT path, such as checks on target hostnames and other request headers which were already sanitized for control bytes, creating an inconsistent security posture within the same module.
From a classification perspective, this flaw aligns with CWE-117, Improper Neutralization of CRLF Sequences in HTTP Headers, also known as HTTP Response/Request Splitting. It is further categorized under CWE-20, Improper Input Validation, due to the failure to sanitize user-controlled or externally influenced data before processing. In terms of offensive security tactics, this vulnerability facilitates techniques associated with MITRE ATT&CK T1134, Access Token Manipulation, if used to alter authentication headers, and potentially T1589, Gather Victim Identity Information, by manipulating requests to exfiltrate internal network details through split responses or redirected traffic. The impact extends beyond simple header injection; it compromises the integrity of HTTP communications over proxies, undermining trust in the connection establishment phase which is critical for secure web browsing and API interactions that rely on proxy infrastructure.
Mitigation strategies must prioritize immediate updates to a patched version of the hackney library where this validation logic has been corrected. For environments unable to upgrade immediately, developers should implement strict input sanitization within their custom proxy_auth_fun callbacks. This involves ensuring that any data returned by the callback is rigorously checked for carriage return characters (ASCII 13) and line feed characters (ASCII 10), as well as null bytes which can also disrupt parsing in some contexts. It is advisable to reject or encode such values rather than passing them through, effectively neutralizing the injection vector at the application layer. Additionally, security teams should review all custom callback implementations across their codebase that interact with proxy authentication mechanisms to ensure consistent validation practices are applied uniformly. Regular static analysis and dynamic testing focused on HTTP header manipulation can help identify similar vulnerabilities in other parts of the system where external data influences internal protocol structures.