Search
Search Results (15 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-97200 | 1 Benoitc | 1 Hackney | 2026-10-26 | N/A |
| Allocation of Resources Without Limits or Throttling vulnerability in hackney_conn in benoitc hackney allows a malicious HTTP server to exhaust client memory via an oversized or highly compressed response body. hackney:request/5 and hackney:body/1 return the whole response body, and nothing bounds how much the connection process buffers. Any server the client requests can trigger it. hackney_conn:read_full_body/2 and the HTTP/2 and HTTP/3 accumulators append every chunk until the body ends. With {auto_decompress, true} the buffered body is then inflated in one step with zlib:gunzip/1 or zlib:inflate/2, which return the whole output at once. This issue affects hackney: from 2.0.0-beta.1 before 4.9.0. | ||||
| CVE-2026-115693 | 1 Benoitc | 1 Hackney | 2026-10-26 | N/A |
| Improper Certificate Validation vulnerability in hackney_ssl in benoitc hackney allows an on-path attacker to impersonate a server pinned to a private certificate authority via a certificate chain that ends in a publicly trusted root. hackney adds {partial_chain, fun hackney_ssl:partial_chain/1} to every verify_peer configuration. The callback returns any certificate in the peer chain whose public key matches a root in the bundled certifi store as the trust anchor, and OTP honours that callback over the configured cacerts. hackney_ssl:merge_ssl_opts/3 kept the callback when the caller replaced the trust store with cacerts or cacertfile in ssl_options, so a connection pinned to a private CA still accepted any chain that carried a publicly trusted root. The hostname check still applies, so the attacker needs a publicly trusted certificate for the pinned hostname. This issue affects hackney: from 1.24.0 before 4.9.0. | ||||
| CVE-2026-113440 | 1 Benoitc | 1 Hackney | 2026-10-26 | N/A |
| 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. | ||||
| CVE-2026-115700 | 1 Benoitc | 1 Hackney | 2026-10-26 | N/A |
| Interpretation Conflict vulnerability in hackney_url in benoitc hackney allows Server Side Request Forgery via a percent-encoded bracketed IPv6 literal or an IP literal with a trailing dot. A host such as %5B%3A%3Affff%3A127%2E0%2E0%2E1%5D (decoding to [::ffff:127.0.0.1]) or 127.0.0.1. is not an IP address to a caller's allowlist built on uri_string:parse/1 and inet:parse_address/1, while hackney connects to the address it denotes. The same applies to a Location target when redirects are followed. The IP-literal gate that hackney_url:normalize/2 applies to a percent-decoded host, added to close the percent-encoded IP bypass of CVE-2026-47076, passes the decoded value to inet_parse:address/1 as is. The connect path in hackney_happy:parse_address/1 drops a surrounding bracket pair, and the resolver ignores a trailing dot, so both forms pass the gate and still reach the literal address. Domain names with a trailing dot and unencoded IPv6 literals are not affected. This issue affects hackney: from 4.0.1 before 4.9.0. | ||||
| CVE-2026-112880 | 1 Benoitc | 1 Hackney | 2026-10-26 | N/A |
| 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. | ||||
| CVE-2026-47075 | 1 Benoitc | 1 Hackney | 2026-07-24 | 7.5 High |
| Improper Neutralization of CRLF Sequences vulnerability in benoitc hackney allows HTTP Request Splitting. hackney does not percent-encode carriage return (\r) or line feed (\n) characters in the URL query component before constructing the HTTP/1.1 request target. Characters outside the grammar defined in RFC 3986 Section 3.4 must be percent-encoded, but hackney_url:make_url/3 passes the query binary directly without validation or escaping. An attacker who can control all or part of a URL passed to hackney can inject raw CRLF sequences into the query string, which are then sent as HTTP line breaks in the request target. This enables injection of arbitrary HTTP headers or splitting of the HTTP request. This issue affects hackney: from 0.13.1 before 4.0.1. | ||||
| CVE-2026-47072 | 1 Benoitc | 1 Hackney | 2026-05-28 | 7.5 High |
| Improper Neutralization of CRLF Sequences ('CRLF Injection') vulnerability in benoitc hackney 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. No CRLF or NUL stripping is performed at any of these four injection sites. An attacker who controls any of these options — for example 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, leading to header injection, credential spoofing toward the upstream server, log and cache poisoning, or request smuggling via intermediary proxies. This issue affects hackney: from 2.0.0 before 4.0.1. | ||||
| CVE-2026-47071 | 1 Benoitc | 1 Hackney | 2026-05-27 | 7.5 High |
| Uncontrolled Resource Consumption vulnerability in benoitc hackney allows Flooding. The SOCKS5 transport in src/hackney_socks5.erl correctly applies the caller-supplied timeout to the SOCKS5 negotiation phase, but then upgrades the connection to TLS using the two-argument form ssl:connect/2, which defaults to an infinite timeout. The Timeout value is in scope at the call site but is not forwarded. A hostile SOCKS5 proxy that completes the SOCKS5 handshake normally and then goes silent (or sends a partial TLS ServerHello and stalls) will cause the connecting process to block indefinitely, regardless of the connect_timeout or recv_timeout options supplied by the caller. This issue affects hackney: from 0.10.0 before 4.0.1. | ||||
| CVE-2026-47070 | 1 Benoitc | 1 Hackney | 2026-05-27 | 6.1 Medium |
| Sensitive Data Exposure vulnerability in benoitc hackney allows Retrieve Embedded Sensitive Data. The HTTP/3 redirect handler in src/hackney_h3.erl passes the original request headers unchanged to the redirect target without performing any cross-origin check. When a client issues 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 those credentials verbatim to the new origin. The main hackney.erl module has maybe_strip_auth_on_redirect/2 (guarded by the location_trusted option) to address CVE-2018-1000007, but hackney_h3.erl is missing this protection entirely. This issue affects hackney: from 3.1.1 before 4.0.1. | ||||
| CVE-2026-47066 | 1 Benoitc | 1 Hackney | 2026-05-27 | 7.5 High |
| Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in benoitc hackney allows Excessive Allocation. The Alt-Svc response header parser in src/hackney_altsvc.erl does not guarantee forward progress. When parse_token/2 receives a non-token, non-whitespace, non-comma byte (e.g. !, @, =, ;), it returns the input unchanged. skip_comma/1 also returns the buffer unchanged when the first byte is not a comma. parse_entries/2 then recurses with identical data, creating a tight infinite tail-recursive loop that pins a scheduler at 100% CPU. The calling process never returns. The entry point parse_and_cache/3 is called synchronously in the connection process on every HTTP response. A single-byte Alt-Svc: ! response header is sufficient to trigger the hang; the header is fully controlled by any HTTP origin the client connects to. This issue affects hackney: from 2.0.0-beta.1 before 4.0.1. | ||||
| CVE-2026-47073 | 1 Benoitc | 1 Hackney | 2026-05-27 | 7.5 High |
| Allocation of Resources Without Limits or Throttling vulnerability in benoitc hackney allows Flooding. The WebSocket client in src/hackney_ws.erl imposes no upper bound on memory consumption in three code paths. First, read_handshake_response/3 accumulates received bytes into a growing buffer with no size cap; the per-receive timeout resets on every chunk, so a server that streams bytes without ever sending \r\n\r\n causes the buffer to grow until memory is exhausted. Second, parse_payload/9 and parse_active_payload/8 do not validate the declared frame payload length against any limit; because RFC 6455 allows payload lengths up to 2^63-1 bytes, a server that announces a very large frame and dribbles bytes causes the accumulation buffer to grow until OOM. Third, the frag_buffer field in #ws_data{} accumulates continuation frames indefinitely; a server that sends an endless stream of non-final (nofin) fragmented frames without ever sending a final (fin) frame grows frag_buffer without bound. In all three cases the attacker only needs to control the WebSocket server the hackney client connects to, with no authentication or special client configuration required. This issue affects hackney: from 2.0.0 before 4.0.1. | ||||
| CVE-2026-47077 | 1 Benoitc | 1 Hackney | 2026-05-27 | 7.5 High |
| Allocation of Resources Without Limits or Throttling vulnerability in benoitc hackney allows Flooding. hackney_h3:await_response_loop/6 accumulates the HTTP/3 response body in memory without any size cap. The after Timeout clause is a per-message inactivity timer that resets on every received chunk, housekeeping message, or settings frame — it is not a wall-clock deadline. A malicious HTTP/3 server that emits one small chunk every Timeout - 1 ms with Fin = false and never sends a final frame keeps the loop alive indefinitely while the accumulation buffer grows linearly without bound, eventually exhausting the BEAM process heap and causing an out-of-memory condition. This issue affects hackney: from 2.0.0 before 4.0.1. | ||||
| CVE-2026-47069 | 1 Benoitc | 1 Hackney | 2026-05-27 | 5.3 Medium |
| Improper Neutralization of CRLF Sequences ('CRLF Injection') vulnerability in benoitc hackney allows HTTP Response Splitting. The hackney_cookie:setcookie/3 function in src/hackney_cookie.erl validates the Name and Value arguments against CRLF and control characters, but concatenates the domain and path options verbatim into the output iolist with no equivalent check. An attacker who controls either option — for example by supplying a Host header value forwarded as the cookie domain, or a request path forwarded as the cookie path — can inject a literal CRLF sequence and arbitrary additional Set-Cookie headers into the HTTP response. This issue affects hackney: from 0.9.0 before 4.0.1. | ||||
| CVE-2026-47067 | 1 Benoitc | 1 Hackney | 2026-05-27 | 7.5 High |
| Allocation of Resources Without Limits or Throttling vulnerability in benoitc hackney allows Flooding. The URL parser in src/hackney_url.erl converts every unrecognized URL scheme to a permanent BEAM atom via binary_to_atom/2. BEAM atoms are never garbage-collected and the atom table defaults to a hard limit of 1,048,576 entries. An attacker who can supply URLs with attacker-chosen scheme prefixes — directly as request targets, as configured webhook URLs, or via Location headers followed during redirects — can exhaust the atom table and crash the entire BEAM VM with system_limit. This issue affects hackney: from 2.0.0 before 4.0.1. | ||||
| CVE-2026-47076 | 1 Benoitc | 1 Hackney | 2026-05-27 | 6.5 Medium |
| Interpretation Conflict vulnerability in benoitc hackney allows Server Side Request Forgery. hackney_url:normalize/2 URL-decodes the host component after the URL has been parsed into a #hackney_url{} record. OTP's uri_string:parse/1 and inet:parse_address/1 do not decode percent-escapes in the host, so a URL such as http://%31%32%37%2E%30%2E%30%2E%31/ is seen by a caller's allowlist validator with host %31%32%37%2E%30%2E%30%2E%31 (not an IP address), which passes the allowlist check. hackney's normalizer then decodes the host to 127.0.0.1 and opens a TCP connection to loopback. Because hackney:request/5 always calls hackney_url:normalize/2 with no opt-out, every request that takes a binary or list URL is affected. The same technique reaches cloud instance metadata services (169.254.169.254), RFC1918 networks, and any admin interface listening on localhost. This issue affects hackney: from 0.13.0 before 4.0.1. | ||||
Page 1 of 1.