CVE-2026-47075: Hackney HTTP Request Splitting Vulnerability

CVE-2026-47075 Overview

CVE-2026-47075 is an HTTP Request Splitting vulnerability in hackney, the Erlang HTTP client maintained by benoitc. The library fails to percent-encode carriage return (\r) and line feed (\n) characters in the URL query component before constructing the HTTP/1.1 request target. An attacker who controls all or part of a URL passed to hackney can inject raw CRLF sequences into the query string. Those bytes are emitted as HTTP line breaks in the request line, enabling injection of arbitrary headers or splitting of the HTTP request. The flaw is tracked as [CWE-93] (Improper Neutralization of CRLF Sequences) and affects hackney versions prior to 4.0.1.

Critical Impact

Attacker-controlled URL inputs can inject arbitrary HTTP headers or split outbound requests, enabling cache poisoning, header smuggling, and SSRF-adjacent attacks against backend services.

Affected Products

• benoitc hackney versions from 0 before 4.0.1
• Erlang/Elixir applications using hackney as their HTTP client
• Downstream libraries depending on hackney for outbound HTTP (for example, HTTPoison)

Discovery Timeline

• 2026-05-25 - CVE-2026-47075 published to NVD
• 2026-05-26 - Last updated in NVD database

Technical Details for CVE-2026-47075

Vulnerability Analysis

The vulnerability resides in hackney_url:make_url/3, which assembles the request target from a base URL, path, and query binary. The function passes the query binary directly into the HTTP request line without validating or escaping characters outside the grammar defined in RFC 3986 Section 3.4. RFC 3986 requires characters outside the reserved and unreserved sets to be percent-encoded. Because hackney performs no such encoding, raw \r, \n, and NUL bytes survive into the wire format of the HTTP/1.1 request line and the HTTP/2 and HTTP/3 :path pseudo-header. The result is classic HTTP Request Splitting: an attacker who supplies a malicious query string causes the client to emit a second header line, additional headers, or even a smuggled second request to the origin server.

Root Cause

The root cause is missing input neutralization on the query component before request line construction. hackney_url:make_url/3 concatenates the query binary as-is, trusting callers to pre-encode the content. Any application that forwards untrusted input into a hackney URL inherits this lack of validation.

Attack Vector

An attacker supplies a crafted URL or query parameter to an application that calls hackney. The attacker embeds CRLF bytes inside the query string. When hackney builds the outbound request, the injected bytes terminate the request line and introduce attacker-controlled headers. Depending on the upstream server, this enables cache poisoning, authentication header overrides, internal endpoint targeting, or request smuggling against shared HTTP infrastructure.

-spec request(pid(), binary(), binary(), list(), binary() | iolist(), timeout(), list()) ->
    {ok, integer(), list()} | {ok, integer(), list(), binary()} | {error, term()}.
request(Pid, Method, Path, Headers, Body, Timeout, ReqOpts) ->
    case valid_request_target(Path) of
        ok -> gen_statem:call(Pid, {request, Method, Path, Headers, Body, ReqOpts}, Timeout);
        Err -> Err
    end.

%% @private GHSA-j9wq: the request target (path + query) is written verbatim
%% into the HTTP/1.1 request line and the HTTP/2 / HTTP/3 :path pseudo-header.
%% Raw CR, LF or NUL bytes let a caller-controlled URL inject extra header
%% lines or split the request. RFC 3986 requires those bytes to be
%% percent-encoded; reject them rather than emit a malformed request.
valid_request_target(Path) when is_binary(Path) ->
    case binary:match(Path, [<<"\r">>, <<"\n">>, <<0>>]) of
        nomatch -> ok;
        _ -> {error, {invalid_request_target, Path}}
    end;
valid_request_target(Path) when is_list(Path) ->
    valid_request_target(iolist_to_binary(Path));
valid_request_target(_) ->
    ok.

Source: GitHub Hackney Commit ca73dd0. The patch in src/hackney_conn.erl adds a valid_request_target/1 guard that rejects \r, \n, and NUL bytes in the request target before dispatch.

Detection Methods for CVE-2026-47075

Indicators of Compromise

• Outbound HTTP requests from Erlang or Elixir application servers containing literal %0D%0A, raw \r\n, or unexpected header lines in the request target.
• Backend or proxy logs showing duplicate Host, Content-Length, or Transfer-Encoding headers correlated with a single client request.
• Application logs recording user-supplied URL parameters containing CR, LF, or NUL bytes prior to a hackney:request/5 or :hackney.request/5 call.

Detection Strategies

• Inventory Erlang and Elixir builds for hackney versions earlier than 4.0.1 via rebar3 tree, mix deps, or SBOM scans.
• Add static analysis rules flagging code paths that pass untrusted strings into hackney_url:make_url/3, hackney:request/5, or HTTPoison wrappers without validation.
• Inspect egress proxy or service mesh logs for request lines containing CR or LF byte sequences originating from application tiers.

Monitoring Recommendations

• Enable structured logging of outbound HTTP request targets and alert on non-ASCII or control-character bytes.
• Monitor for anomalous duplicate-header patterns at intermediate proxies, load balancers, and CDNs.
• Track dependency drift in CI to surface any rollback to hackney versions below 4.0.1.

How to Mitigate CVE-2026-47075

Immediate Actions Required

• Upgrade hackney to version 4.0.1 or later across all Erlang and Elixir services.
• Identify and patch transitive consumers such as HTTPoison that pin older hackney releases.
• Audit application code that forwards user-controlled input into URL paths or query strings handled by hackney.
• Add input validation to reject CR, LF, and NUL bytes in any URL component before invoking the HTTP client.

Patch Information

The fix is delivered in commit ca73dd0aba0ed557449c18288bf07241671a43c9 and shipped in hackney4.0.1. The patch introduces valid_request_target/1 in src/hackney_conn.erl, which rejects request targets containing \r, \n, or NUL and returns {error, {invalid_request_target, Path}}. Full details are in GitHub Security Advisory GHSA-j9wq-vxxc-94wf and the CNA CVE-2026-47075 Record.

Workarounds

• Percent-encode URL query strings using hackney_url:urlencode/1 or equivalent before passing values to hackney.
• Wrap calls to hackney:request/5 with a guard that rejects binaries containing \r, \n, or NUL bytes.
• Restrict outbound HTTP from application tiers through an egress proxy that normalizes or drops requests containing control characters in the request target.

# Pin the patched version in rebar.config
{deps, [
    {hackney, "4.0.1"}
]}.

# Or in mix.exs for Elixir projects
# {:hackney, "~> 4.0.1"}

# Then refresh dependencies
rebar3 upgrade hackney
# mix deps.update hackney