Benoit Chesneau

An HTTP Request Splitting issue exists in `hackney http connect` due to improper neutralization of CRLF sequences in HTTP headers. When an HTTP CONNECT proxy returns a 407 response, the function `hackney http connect:handle proxy auth/11` executes a `proxy auth fun` callback and writes the returned binary directly into the `Proxy-Authorization` line of the retry request without validation. If the returned value contains a Carriage Return (CR), Line Feed (LF), or NUL byte, an attacker can inject additional header lines into the request sent to the proxy. This occurs when the callback derives its value from untrusted data, such as the proxy's challenge headers.

An issue exists where a redirecting server can obtain `basic auth` and `cookie` credentials through a same-host redirect to a different scheme or port. When `follow redirect` is enabled, the function `hackney:follow redirect/10` in `src/hackney.erl` re-issues requests to the `Location` target. The check performed by `hackney:maybe strip auth on redirect/3` only compares the hostname of the current and redirect URLs. Consequently, a redirect from `https` to `http` on the same host sends the `Authorization` and `Cookie` headers in cleartext, allowing an on-path attacker to intercept them. Similarly, a redirect to a different port on the same host sends these credentials to a different service. This occurs over HTTP/1.1 and HTTP/2 when `location trusted` is not set.

An interpretation conflict in `hackney url` allows Server Side Request Forgery (SSRF). This occurs when a host is provided as a percent-encoded bracketed IPv6 literal or an IP literal with a trailing dot. While a caller's allowlist using `uri string:parse/1` and `inet:parse address/1` may not recognize these as IP addresses, hackney still connects to the denoted address. This also affects `Location` targets during redirects. The issue stems from `hackney url:normalize/2` passing decoded values to `inet parse:address/1` as is, while the connect path in `hackney happy:parse address/1` drops surrounding brackets and the resolver ignores trailing dots, allowing these forms to bypass the IP-literal gate. Applications using an IP allowlist to prevent requests to internal addresses, such as loopback or link-local metadata, are susceptible.

A resource allocation issue in `hackney conn` allows a malicious HTTP server to exhaust client memory by sending an oversized or highly compressed response body. The functions `hackney:request/5` and `hackney:body/1` return the entire response body without limits on how much the connection process buffers. Specifically, `hackney conn:read full body/2` and the HTTP/2 and HTTP/3 accumulators append every chunk until the body ends. When the `{auto decompress, true}` option is used, the buffered body is inflated in a single step using `zlib:gunzip/1` or `zlib:inflate/2`, which return the entire output at once. This can lead to significant memory amplification; for example, a 1 MB gzip body can inflate to 1 GB.

An infinite loop exists in the Alt-Svc response header parser within `src/hackney altsvc.erl`. When the `parse token/2` function receives a byte that is not a token, whitespace, or comma (such as !, @, =, or ;), it returns the input unchanged. Similarly, the `skip comma/1` function returns the buffer unchanged if the first byte is not a comma. This causes the `parse entries/2` function to recurse with identical data, creating a tight infinite tail-recursive loop that consumes 100% of the CPU scheduler and prevents the calling process from returning. The entry point `parse and cache/3` is called synchronously during every HTTP response, meaning a single-byte `Alt-Svc: !` response header from any HTTP origin can trigger the hang.

An issue in the URL parser within `src/hackney url.erl` allows for resource exhaustion. The parser uses the `binary to atom/2` function to convert unrecognized URL schemes into permanent BEAM atoms. Since BEAM atoms are not garbage-collected and the atom table has a hard limit of 1,048,576 entries, an attacker can exhaust this table by providing URLs with custom scheme prefixes. This can be achieved through request targets, configured webhook URLs, or Location headers during redirects, leading to a crash of the entire BEAM VM with a `system limit` error.

Improper Neutralization of CRLF Sequences, also known as CRLF Injection, allows HTTP Response Splitting. The `setcookie/3` function in `src/hackney cookie.erl` validates Name and Value arguments against CRLF and control characters but concatenates the domain and path options into the output iolist without equivalent checks. An attacker controlling these options, such as by providing a Host header value as the cookie domain or a request path as the cookie path, can inject literal CRLF sequences and arbitrary additional Set-Cookie headers into the HTTP response.

A sensitive data exposure issue exists where the HTTP/3 redirect handler in `src/hackney h3.erl` passes original request headers to a redirect target without performing cross-origin checks. If a client makes an HTTP/3 request with `follow redirect` enabled and includes `Authorization` or `Cookie` headers, a server responding with a 3xx redirect to a different host will cause the client to forward these credentials verbatim to the new origin. This occurs because `hackney h3.erl` lacks the protection provided by the `maybe strip auth on redirect()` function found in the main `hackney.erl` module.

Uncontrolled Resource Consumption in the SOCKS5 transport within `src/hackney socks5.erl` allows flooding. While the caller-supplied timeout is applied during the SOCKS5 negotiation phase, the connection upgrade to TLS via the `ssl:connect/2` function defaults to an infinite timeout because the `Timeout` variable is not forwarded. Consequently, a hostile SOCKS5 proxy that completes the handshake and then stalls or sends a partial TLS ServerHello can cause the connecting process to block indefinitely, ignoring the `connect timeout` or `recv timeout` options.

Improper Neutralization of CRLF Sequences, also known as CRLF Injection, allows HTTP Request/Response Splitting. The WebSocket upgrade code in `src/hackney ws.erl` copies the host, path, headers (`ExtraHeaders`), and protocols options from the caller-supplied opts map into the internal `#ws data{}` record in `init/1` and then splices them verbatim into the raw HTTP/1.1 upgrade request by binary concatenation in `do handshake/1`. Because no CRLF or NUL stripping is performed at these four injection sites, an attacker controlling these options—such as by forwarding URL components or header values from untrusted input into `hackney ws:start link/1`—can inject arbitrary HTTP headers into the outbound WebSocket upgrade request. This can lead to header injection, credential spoofing toward the upstream server, log and cache poisoning, or request smuggling via intermediary proxies.

The WebSocket client in `src/hackney ws.erl` lacks upper bounds on memory consumption across three code paths, allowing for flooding. First, the `read handshake response/3` function accumulates received bytes into a buffer without a size cap; a server streaming bytes without the required termination sequence causes the buffer to grow until memory is exhausted. Second, the `parse payload/9` and `parse active payload/8` functions do not validate declared frame payload lengths, which can be up to 2^63-1 bytes per RFC 6455, leading to Out-of-Memory (OOM) conditions when a server announces a very large frame. Third, the `frag buffer` field in `#ws data{}` accumulates continuation frames indefinitely if a server sends a stream of non-final fragmented frames without a final frame. An attacker only needs to control the WebSocket server the client connects to, requiring no authentication or special configuration.

Improper Neutralization of CRLF Sequences allows HTTP Request Splitting. The software fails to percent-encode carriage return (`r`) or line feed (` `) characters in the URL query component before constructing the HTTP/1.1 request target. Specifically, the `hackney url:make url/3` function passes the query binary directly without validation or escaping, violating RFC 3986 Section 3.4. An attacker controlling part of a URL can inject raw CRLF sequences into the query string, enabling the injection of arbitrary HTTP headers or the splitting of the HTTP request.

An interpretation conflict allows Server Side Request Forgery (SSRF), a flaw where an attacker can induce the server to make requests to an unintended location. The function `hackney url:normalize/2` URL-decodes the host component after the URL has been parsed into a `#hackney url{}` record. Since OTP's `uri string:parse/1` and `inet:parse address/1` do not decode percent-escapes in the host, a URL containing percent-encoded characters can bypass allowlist validators that do not recognize the encoded string as an IP address. Subsequently, the normalizer decodes the host (e.g., converting `%31%32%37%2E%30%2E%30%2E%31` to `127.0.0.1`), enabling TCP connections to the loopback interface, cloud instance metadata services (169.254.169.254), RFC1918 networks, and local admin interfaces. This occurs because `hackney:request/5` always invokes `hackney url:normalize/2` without an opt-out mechanism for requests using binary or list URLs.

An allocation of resources without limits or throttling allows flooding. The function `await response loop/6` in `hackney h3` accumulates the HTTP/3 response body in memory without a size cap. Because the timeout clause acts as a per-message inactivity timer that resets upon receiving chunks, housekeeping messages, or settings frames rather than a fixed deadline, a malicious HTTP/3 server can keep the loop active indefinitely. By emitting small chunks just before the timeout expires with `Fin` set to false and omitting a final frame, the server causes the accumulation buffer to grow linearly, exhausting the BEAM process heap and leading to an out-of-memory condition. This issue occurs when the application uses the HTTP/3 transport via `hackney h3` or by passing `{transport, h3}` to `hackney:request/5`.