Benoit Chesneau

**Name of the Vulnerable Software and Affected Versions** hackney versions 2.0.0-beta.1 through 4.0.0 **Description** 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. **Recommendations** Update hackney to version 4.0.1.

**Name of the Vulnerable Software and Affected Versions** hackney versions 2.0.0 through 4.0.0 **Description** 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. **Recommendations** Update to version 4.0.1.

**Name of the Vulnerable Software and Affected Versions** hackney versions 0.9.0 through 4.0.0 **Description** 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. **Recommendations** Update to version 4.0.1.

**Name of the Vulnerable Software and Affected Versions** benoitc hackney versions 3.1.1 through 4.0.0 **Description** 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. **Recommendations** Update to version 4.0.1.

**Name of the Vulnerable Software and Affected Versions** hackney versions 0.10.0 through 4.0.0 **Description** 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. **Recommendations** Update hackney to version 4.0.1.

**Name of the Vulnerable Software and Affected Versions** hackney versions 2.0.0 through 4.0.0 **Description** 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. **Recommendations** Update to version 4.0.1.

**Name of the Vulnerable Software and Affected Versions** hackney versions 2.0.0 through 4.0.0 **Description** 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. **Recommendations** Update to version 4.0.1.

**Name of the Vulnerable Software and Affected Versions** hackney versions 0 through 4.0.0 **Description** 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. **Recommendations** Update to version 4.0.1.

**Name of the Vulnerable Software and Affected Versions** benoitc hackney versions 0.13.0 through 4.0.0 **Description** 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. **Recommendations** Update benoitc hackney to version 4.0.1.

**Name of the Vulnerable Software and Affected Versions** hackney versions 2.0.0 through 4.0.0 **Description** 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`. **Recommendations** Update to version 4.0.1. As a temporary mitigation, avoid using the HTTP/3 transport by not calling `hackney h3` directly and avoiding the `{transport, h3}` option in `hackney:request/5`.