hackney

Summary

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.

Details

1. Unbounded accumulation. hackney:request/5 with a body, and hackney:body/1 after start_response/1, read the response in src/hackney_conn.erl through read_full_body/2, which appends each chunk to a binary accumulator until the body ends. The HTTP/2 and HTTP/3 synchronous paths accumulate stream data the same way. No option caps the size.

2. One-step decompression. With {auto_decompress, true} hackney sends Accept-Encoding: gzip, deflate. Once the body is complete, maybe_decompress_body/2 dispatches on Content-Encoding to decompress_gzip/1 (zlib:gunzip/1) or decompress_deflate/1 (zlib:inflate/2). Both return the whole output at once, so the inflated size is bounded only by the compression ratio. The report measured a 1 MB gzip body inflating to 1 GB on hackney 4.8.4.

Proof of concept

1. Build a gzip stream whose inflated size is 1 GB from a reused 64 KB chunk of zero bytes (deflate with window bits 31, best compression). The stream is about 1 MB on the wire.
2. Start a TCP listener on loopback that accepts one connection, reads the request, and answers HTTP/1.1 200 OK with Content-Encoding: gzip, a Content-Length matching the stream, Connection: close, and the stream as body.
3. From a node running a vulnerable hackney, call hackney:request(get, Url, [], <<>>, [{auto_decompress, true}, with_body]) against that listener.
4. Observe the returned body of 1,048,576,000 bytes and the VM memory growing by about 1.8 GB for a 1,019,197 byte response. A larger stream, or an endless body without auto_decompress, drives the node out of memory.

Impact

A server the client requests can make the client allocate memory proportional to the body it sends, or to its decompressed size, until the node runs out of memory.

Workarounds

Leave auto_decompress disabled (the default). Without it hackney_conn:maybe_decompress_body/2 never inflates the body, which closes the amplification half. The uncapped raw body read has no workaround.

Summary

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.

Details

1. Default trust options. hackney_ssl:check_hostname_opts/1 builds the verify_peer options for every TLS connection: the certifi cacerts, a hostname verify_fun, and {partial_chain, fun hackney_ssl:partial_chain/1}. The callback walks the peer chain and returns {trusted_ca, Cert} for the first certificate whose public key matches a root in the bundled certifi store, which lets OTP accept chains that end in a cross-signed root.

2. Merge keeps the callback. When the caller passes ssl_options, hackney_ssl:merge_ssl_opts/3 merges them over the defaults with the caller's values winning per key. cacerts or cacertfile replace the trust store, and a cacertfile removes the default cacerts, but partial_chain has no counterpart in the caller's options and stays.

3. Validation. OTP consults partial_chain before the configured trust store. A peer chain that carries any publicly trusted root therefore gets that root as its trust anchor, and the pinned cacerts are never consulted. Only the hostname verify_fun still constrains the attacker.

Impact

An attacker positioned between the client and a server pinned to a private CA, holding a publicly trusted certificate for the pinned hostname, can impersonate the server and read or modify the traffic the client sends and receives.

Workarounds

Pass your own {partial_chain, Fun} in ssl_options alongside cacerts or cacertfile. A caller-supplied partial_chain replaces hackney's in the merge, and a callback that returns unknown_ca makes OTP validate against the configured cacerts only.

Configurations

The caller passes cacerts or cacertfile in ssl_options to restrict trust to a private CA, without a partial_chain of its own. Connections that use hackney's default certifi trust store are not affected.

Summary

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.

Details

1. Redirect handling. With follow_redirect set, hackney:request/5 hands a 3xx response to hackney:follow_redirect/10 in src/hackney.erl, which resolves the Location header against the current URL and calls hackney:request/5 again with the caller's options and an empty header list. HTTP/1.1 and HTTP/2 share this path.

2. Host-only comparison. Before the new request, hackney:maybe_strip_auth_on_redirect/3 removes the basic_auth and cookie options when the redirect leaves the current host, unless location_trusted is set. It compared #hackney_url.host of the two URLs.

3. Consequence. A redirect that keeps the hostname but changes the scheme or the port passes the check, so the new request carries the same Authorization and Cookie headers. From https to http they travel in cleartext; to another port they reach a different service on the same host.

Impact

A server that answers a credentialed request with a same-host redirect to plain HTTP exposes the client's Authorization and Cookie headers to anyone on the network path, and a redirect to another port delivers them to whatever service listens there. The captured values can be replayed against the original origin.

Workarounds

Disable follow_redirect and handle the Location header in the application, or pass the credentials as explicit Authorization and Cookie request headers instead of the basic_auth and cookie options. hackney:follow_redirect/10 issues the redirected request with an empty header list, so explicit headers reach the first server only.

Configurations

The request is made with follow_redirect enabled and the basic_auth or cookie option set, over HTTP/1.1 or HTTP/2, without location_trusted. Credentials passed as explicit request headers are not forwarded on redirects and are not affected.

Summary

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.

Details

1. The gate. hackney_url:normalize/2 in src/hackney_url.erl percent-decodes a host that is not already an IP literal and raises invalid_url_host when inet_parse:address/1 accepts the decoded value. This closed the plain percent-encoded IP case.

2. What the connect path accepts. hackney_happy:parse_address/1 removes a surrounding [...] pair before calling inet:parse_address/1, and the resolver treats a trailing dot as the root label. Neither form is accepted by inet_parse:address/1, so [::ffff:127.0.0.1] and 127.0.0.1. pass the gate.

3. Result. A percent-encoded bracketed IPv6 literal such as %5B%3A%3Affff%3A127%2E0%2E0%2E1%5D, or an IPv4 literal with a trailing dot, is not an IP address to a caller's check based on uri_string:parse/1 and inet:parse_address/1, but hackney connects to the address it denotes. The same applies to a Location target when redirects are followed. The fix strips one bracket pair and one trailing dot in ip_candidate/1 before the gate.

Impact

An application that checks user-supplied URLs against an IP allowlist before handing them to hackney can be made to request loopback, link-local metadata and private-network addresses that the allowlist rejects when they are written plainly.

Workarounds

Run the allowlist on the host that hackney_url:normalize/1 returns for the parsed URL, and strip a surrounding bracket pair and a trailing dot from it before the IP check, so the check sees the same address the connect path uses.

Configurations

The application passes URLs that an untrusted party can influence to hackney and relies on its own host allowlist, built on uri_string:parse/1 or inet:parse_address/1, to keep requests away from internal addresses.

Summary

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.

Details

1. Challenge. hackney_http_connect:do_handshake_with_auth/9 in src/hackney_http_connect.erl sends the CONNECT request to the proxy. When the proxy answers 407 and the proxy_auth_fun option is set, it hands the status code and the parsed response headers to hackney_http_connect:handle_proxy_auth/11.

2. Callback result. handle_proxy_auth/11 calls the caller's proxy_auth_fun with those two values. On {ok, AuthHeader} it removes any existing Proxy-Authorization header and appends the binary <<"Proxy-Authorization: ", AuthHeader/binary>> to the header list, then retries the handshake with it.

3. Splitting. The header list is joined with CRLF into the CONNECT request. A CR, LF or NUL byte inside AuthHeader therefore ends the Proxy-Authorization line early and the rest is sent as further header lines. The target host and the request headers go through control-byte checks on this path; the callback result did not. The fix applies the same has_ctl_bytes/1 check to it and returns {error, {proxy_auth_error, invalid_header}}.

Impact

A party who controls what the application's proxy_auth_fun returns, for instance through the challenge headers of a proxy it can influence, can add header lines to the CONNECT request the client sends to its proxy.

Workarounds

Check the value your proxy_auth_fun is about to return for CR, LF and NUL bytes and return {error, Reason} instead when one is present. The callback runs in the application, so the check can be made there.

Configurations

The client connects through an HTTP CONNECT proxy with the proxy_auth_fun option set, and the callback builds its result from data an untrusted party can influence, such as the proxy's 407 challenge headers. Deployments without proxy_auth_fun, or whose callback returns a fixed credential, are not affected.

Summary

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.

Details

1. Unbounded accumulation. hackney:request/5 with a body, and hackney:body/1 after start_response/1, read the response in src/hackney_conn.erl through read_full_body/2, which appends each chunk to a binary accumulator until the body ends. The HTTP/2 and HTTP/3 synchronous paths accumulate stream data the same way. No option caps the size.

2. One-step decompression. With {auto_decompress, true} hackney sends Accept-Encoding: gzip, deflate. Once the body is complete, maybe_decompress_body/2 dispatches on Content-Encoding to decompress_gzip/1 (zlib:gunzip/1) or decompress_deflate/1 (zlib:inflate/2). Both return the whole output at once, so the inflated size is bounded only by the compression ratio. The report measured a 1 MB gzip body inflating to 1 GB on hackney 4.8.4.

Proof of concept

1. Build a gzip stream whose inflated size is 1 GB from a reused 64 KB chunk of zero bytes (deflate with window bits 31, best compression). The stream is about 1 MB on the wire.
2. Start a TCP listener on loopback that accepts one connection, reads the request, and answers HTTP/1.1 200 OK with Content-Encoding: gzip, a Content-Length matching the stream, Connection: close, and the stream as body.
3. From a node running a vulnerable hackney, call hackney:request(get, Url, [], <<>>, [{auto_decompress, true}, with_body]) against that listener.
4. Observe the returned body of 1,048,576,000 bytes and the VM memory growing by about 1.8 GB for a 1,019,197 byte response. A larger stream, or an endless body without auto_decompress, drives the node out of memory.

Impact

A server the client requests can make the client allocate memory proportional to the body it sends, or to its decompressed size, until the node runs out of memory.

Workarounds

Leave auto_decompress disabled (the default). Without it hackney_conn:maybe_decompress_body/2 never inflates the body, which closes the amplification half. The uncapped raw body read has no workaround.

Summary

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.

Details

1. Default trust options. hackney_ssl:check_hostname_opts/1 builds the verify_peer options for every TLS connection: the certifi cacerts, a hostname verify_fun, and {partial_chain, fun hackney_ssl:partial_chain/1}. The callback walks the peer chain and returns {trusted_ca, Cert} for the first certificate whose public key matches a root in the bundled certifi store, which lets OTP accept chains that end in a cross-signed root.

2. Merge keeps the callback. When the caller passes ssl_options, hackney_ssl:merge_ssl_opts/3 merges them over the defaults with the caller's values winning per key. cacerts or cacertfile replace the trust store, and a cacertfile removes the default cacerts, but partial_chain has no counterpart in the caller's options and stays.

3. Validation. OTP consults partial_chain before the configured trust store. A peer chain that carries any publicly trusted root therefore gets that root as its trust anchor, and the pinned cacerts are never consulted. Only the hostname verify_fun still constrains the attacker.

Impact

An attacker positioned between the client and a server pinned to a private CA, holding a publicly trusted certificate for the pinned hostname, can impersonate the server and read or modify the traffic the client sends and receives.

Workarounds

Pass your own {partial_chain, Fun} in ssl_options alongside cacerts or cacertfile. A caller-supplied partial_chain replaces hackney's in the merge, and a callback that returns unknown_ca makes OTP validate against the configured cacerts only.

Configurations

The caller passes cacerts or cacertfile in ssl_options to restrict trust to a private CA, without a partial_chain of its own. Connections that use hackney's default certifi trust store are not affected.

Summary

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.

Details

1. Redirect handling. With follow_redirect set, hackney:request/5 hands a 3xx response to hackney:follow_redirect/10 in src/hackney.erl, which resolves the Location header against the current URL and calls hackney:request/5 again with the caller's options and an empty header list. HTTP/1.1 and HTTP/2 share this path.

2. Host-only comparison. Before the new request, hackney:maybe_strip_auth_on_redirect/3 removes the basic_auth and cookie options when the redirect leaves the current host, unless location_trusted is set. It compared #hackney_url.host of the two URLs.

3. Consequence. A redirect that keeps the hostname but changes the scheme or the port passes the check, so the new request carries the same Authorization and Cookie headers. From https to http they travel in cleartext; to another port they reach a different service on the same host.

Impact

A server that answers a credentialed request with a same-host redirect to plain HTTP exposes the client's Authorization and Cookie headers to anyone on the network path, and a redirect to another port delivers them to whatever service listens there. The captured values can be replayed against the original origin.

Workarounds

Disable follow_redirect and handle the Location header in the application, or pass the credentials as explicit Authorization and Cookie request headers instead of the basic_auth and cookie options. hackney:follow_redirect/10 issues the redirected request with an empty header list, so explicit headers reach the first server only.

Configurations

The request is made with follow_redirect enabled and the basic_auth or cookie option set, over HTTP/1.1 or HTTP/2, without location_trusted. Credentials passed as explicit request headers are not forwarded on redirects and are not affected.

Summary

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.

Details

1. The gate. hackney_url:normalize/2 in src/hackney_url.erl percent-decodes a host that is not already an IP literal and raises invalid_url_host when inet_parse:address/1 accepts the decoded value. This closed the plain percent-encoded IP case.

2. What the connect path accepts. hackney_happy:parse_address/1 removes a surrounding [...] pair before calling inet:parse_address/1, and the resolver treats a trailing dot as the root label. Neither form is accepted by inet_parse:address/1, so [::ffff:127.0.0.1] and 127.0.0.1. pass the gate.

3. Result. A percent-encoded bracketed IPv6 literal such as %5B%3A%3Affff%3A127%2E0%2E0%2E1%5D, or an IPv4 literal with a trailing dot, is not an IP address to a caller's check based on uri_string:parse/1 and inet:parse_address/1, but hackney connects to the address it denotes. The same applies to a Location target when redirects are followed. The fix strips one bracket pair and one trailing dot in ip_candidate/1 before the gate.

Impact

An application that checks user-supplied URLs against an IP allowlist before handing them to hackney can be made to request loopback, link-local metadata and private-network addresses that the allowlist rejects when they are written plainly.

Workarounds

Run the allowlist on the host that hackney_url:normalize/1 returns for the parsed URL, and strip a surrounding bracket pair and a trailing dot from it before the IP check, so the check sees the same address the connect path uses.

Configurations

The application passes URLs that an untrusted party can influence to hackney and relies on its own host allowlist, built on uri_string:parse/1 or inet:parse_address/1, to keep requests away from internal addresses.

Summary

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.

Details

1. Challenge. hackney_http_connect:do_handshake_with_auth/9 in src/hackney_http_connect.erl sends the CONNECT request to the proxy. When the proxy answers 407 and the proxy_auth_fun option is set, it hands the status code and the parsed response headers to hackney_http_connect:handle_proxy_auth/11.

2. Callback result. handle_proxy_auth/11 calls the caller's proxy_auth_fun with those two values. On {ok, AuthHeader} it removes any existing Proxy-Authorization header and appends the binary <<"Proxy-Authorization: ", AuthHeader/binary>> to the header list, then retries the handshake with it.

3. Splitting. The header list is joined with CRLF into the CONNECT request. A CR, LF or NUL byte inside AuthHeader therefore ends the Proxy-Authorization line early and the rest is sent as further header lines. The target host and the request headers go through control-byte checks on this path; the callback result did not. The fix applies the same has_ctl_bytes/1 check to it and returns {error, {proxy_auth_error, invalid_header}}.

Impact

A party who controls what the application's proxy_auth_fun returns, for instance through the challenge headers of a proxy it can influence, can add header lines to the CONNECT request the client sends to its proxy.

Workarounds

Check the value your proxy_auth_fun is about to return for CR, LF and NUL bytes and return {error, Reason} instead when one is present. The callback runs in the application, so the check can be made there.

Configurations

The client connects through an HTTP CONNECT proxy with the proxy_auth_fun option set, and the callback builds its result from data an untrusted party can influence, such as the proxy's 407 challenge headers. Deployments without proxy_auth_fun, or whose callback returns a fixed credential, are not affected.

Summary

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.

Details

1. Unbounded accumulation. hackney:request/5 with a body, and hackney:body/1 after start_response/1, read the response in src/hackney_conn.erl through read_full_body/2, which appends each chunk to a binary accumulator until the body ends. The HTTP/2 and HTTP/3 synchronous paths accumulate stream data the same way. No option caps the size.

2. One-step decompression. With {auto_decompress, true} hackney sends Accept-Encoding: gzip, deflate. Once the body is complete, maybe_decompress_body/2 dispatches on Content-Encoding to decompress_gzip/1 (zlib:gunzip/1) or decompress_deflate/1 (zlib:inflate/2). Both return the whole output at once, so the inflated size is bounded only by the compression ratio. The report measured a 1 MB gzip body inflating to 1 GB on hackney 4.8.4.

Proof of concept

1. Build a gzip stream whose inflated size is 1 GB from a reused 64 KB chunk of zero bytes (deflate with window bits 31, best compression). The stream is about 1 MB on the wire.
2. Start a TCP listener on loopback that accepts one connection, reads the request, and answers HTTP/1.1 200 OK with Content-Encoding: gzip, a Content-Length matching the stream, Connection: close, and the stream as body.
3. From a node running a vulnerable hackney, call hackney:request(get, Url, [], <<>>, [{auto_decompress, true}, with_body]) against that listener.
4. Observe the returned body of 1,048,576,000 bytes and the VM memory growing by about 1.8 GB for a 1,019,197 byte response. A larger stream, or an endless body without auto_decompress, drives the node out of memory.

Impact

A server the client requests can make the client allocate memory proportional to the body it sends, or to its decompressed size, until the node runs out of memory.

Workarounds

Leave auto_decompress disabled (the default). Without it hackney_conn:maybe_decompress_body/2 never inflates the body, which closes the amplification half. The uncapped raw body read has no workaround.

Summary

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.

Details

1. Default trust options. hackney_ssl:check_hostname_opts/1 builds the verify_peer options for every TLS connection: the certifi cacerts, a hostname verify_fun, and {partial_chain, fun hackney_ssl:partial_chain/1}. The callback walks the peer chain and returns {trusted_ca, Cert} for the first certificate whose public key matches a root in the bundled certifi store, which lets OTP accept chains that end in a cross-signed root.

2. Merge keeps the callback. When the caller passes ssl_options, hackney_ssl:merge_ssl_opts/3 merges them over the defaults with the caller's values winning per key. cacerts or cacertfile replace the trust store, and a cacertfile removes the default cacerts, but partial_chain has no counterpart in the caller's options and stays.

3. Validation. OTP consults partial_chain before the configured trust store. A peer chain that carries any publicly trusted root therefore gets that root as its trust anchor, and the pinned cacerts are never consulted. Only the hostname verify_fun still constrains the attacker.

Impact

An attacker positioned between the client and a server pinned to a private CA, holding a publicly trusted certificate for the pinned hostname, can impersonate the server and read or modify the traffic the client sends and receives.

Workarounds

Pass your own {partial_chain, Fun} in ssl_options alongside cacerts or cacertfile. A caller-supplied partial_chain replaces hackney's in the merge, and a callback that returns unknown_ca makes OTP validate against the configured cacerts only.

Configurations

The caller passes cacerts or cacertfile in ssl_options to restrict trust to a private CA, without a partial_chain of its own. Connections that use hackney's default certifi trust store are not affected.

Summary

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.

Details

1. Redirect handling. With follow_redirect set, hackney:request/5 hands a 3xx response to hackney:follow_redirect/10 in src/hackney.erl, which resolves the Location header against the current URL and calls hackney:request/5 again with the caller's options and an empty header list. HTTP/1.1 and HTTP/2 share this path.

2. Host-only comparison. Before the new request, hackney:maybe_strip_auth_on_redirect/3 removes the basic_auth and cookie options when the redirect leaves the current host, unless location_trusted is set. It compared #hackney_url.host of the two URLs.

3. Consequence. A redirect that keeps the hostname but changes the scheme or the port passes the check, so the new request carries the same Authorization and Cookie headers. From https to http they travel in cleartext; to another port they reach a different service on the same host.

Impact

A server that answers a credentialed request with a same-host redirect to plain HTTP exposes the client's Authorization and Cookie headers to anyone on the network path, and a redirect to another port delivers them to whatever service listens there. The captured values can be replayed against the original origin.

Workarounds

Disable follow_redirect and handle the Location header in the application, or pass the credentials as explicit Authorization and Cookie request headers instead of the basic_auth and cookie options. hackney:follow_redirect/10 issues the redirected request with an empty header list, so explicit headers reach the first server only.

Configurations

The request is made with follow_redirect enabled and the basic_auth or cookie option set, over HTTP/1.1 or HTTP/2, without location_trusted. Credentials passed as explicit request headers are not forwarded on redirects and are not affected.

Summary

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.

Details

1. The gate. hackney_url:normalize/2 in src/hackney_url.erl percent-decodes a host that is not already an IP literal and raises invalid_url_host when inet_parse:address/1 accepts the decoded value. This closed the plain percent-encoded IP case.

2. What the connect path accepts. hackney_happy:parse_address/1 removes a surrounding [...] pair before calling inet:parse_address/1, and the resolver treats a trailing dot as the root label. Neither form is accepted by inet_parse:address/1, so [::ffff:127.0.0.1] and 127.0.0.1. pass the gate.

3. Result. A percent-encoded bracketed IPv6 literal such as %5B%3A%3Affff%3A127%2E0%2E0%2E1%5D, or an IPv4 literal with a trailing dot, is not an IP address to a caller's check based on uri_string:parse/1 and inet:parse_address/1, but hackney connects to the address it denotes. The same applies to a Location target when redirects are followed. The fix strips one bracket pair and one trailing dot in ip_candidate/1 before the gate.

Impact

An application that checks user-supplied URLs against an IP allowlist before handing them to hackney can be made to request loopback, link-local metadata and private-network addresses that the allowlist rejects when they are written plainly.

Workarounds

Run the allowlist on the host that hackney_url:normalize/1 returns for the parsed URL, and strip a surrounding bracket pair and a trailing dot from it before the IP check, so the check sees the same address the connect path uses.

Configurations

The application passes URLs that an untrusted party can influence to hackney and relies on its own host allowlist, built on uri_string:parse/1 or inet:parse_address/1, to keep requests away from internal addresses.

Summary

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.

Details

1. Challenge. hackney_http_connect:do_handshake_with_auth/9 in src/hackney_http_connect.erl sends the CONNECT request to the proxy. When the proxy answers 407 and the proxy_auth_fun option is set, it hands the status code and the parsed response headers to hackney_http_connect:handle_proxy_auth/11.

2. Callback result. handle_proxy_auth/11 calls the caller's proxy_auth_fun with those two values. On {ok, AuthHeader} it removes any existing Proxy-Authorization header and appends the binary <<"Proxy-Authorization: ", AuthHeader/binary>> to the header list, then retries the handshake with it.

3. Splitting. The header list is joined with CRLF into the CONNECT request. A CR, LF or NUL byte inside AuthHeader therefore ends the Proxy-Authorization line early and the rest is sent as further header lines. The target host and the request headers go through control-byte checks on this path; the callback result did not. The fix applies the same has_ctl_bytes/1 check to it and returns {error, {proxy_auth_error, invalid_header}}.

Impact

A party who controls what the application's proxy_auth_fun returns, for instance through the challenge headers of a proxy it can influence, can add header lines to the CONNECT request the client sends to its proxy.

Workarounds

Check the value your proxy_auth_fun is about to return for CR, LF and NUL bytes and return {error, Reason} instead when one is present. The callback runs in the application, so the check can be made there.

Configurations

The client connects through an HTTP CONNECT proxy with the proxy_auth_fun option set, and the callback builds its result from data an untrusted party can influence, such as the proxy's 407 challenge headers. Deployments without proxy_auth_fun, or whose callback returns a fixed credential, are not affected.

Summary

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.

Details

1. Unbounded accumulation. hackney:request/5 with a body, and hackney:body/1 after start_response/1, read the response in src/hackney_conn.erl through read_full_body/2, which appends each chunk to a binary accumulator until the body ends. The HTTP/2 and HTTP/3 synchronous paths accumulate stream data the same way. No option caps the size.

2. One-step decompression. With {auto_decompress, true} hackney sends Accept-Encoding: gzip, deflate. Once the body is complete, maybe_decompress_body/2 dispatches on Content-Encoding to decompress_gzip/1 (zlib:gunzip/1) or decompress_deflate/1 (zlib:inflate/2). Both return the whole output at once, so the inflated size is bounded only by the compression ratio. The report measured a 1 MB gzip body inflating to 1 GB on hackney 4.8.4.

Proof of concept

1. Build a gzip stream whose inflated size is 1 GB from a reused 64 KB chunk of zero bytes (deflate with window bits 31, best compression). The stream is about 1 MB on the wire.
2. Start a TCP listener on loopback that accepts one connection, reads the request, and answers HTTP/1.1 200 OK with Content-Encoding: gzip, a Content-Length matching the stream, Connection: close, and the stream as body.
3. From a node running a vulnerable hackney, call hackney:request(get, Url, [], <<>>, [{auto_decompress, true}, with_body]) against that listener.
4. Observe the returned body of 1,048,576,000 bytes and the VM memory growing by about 1.8 GB for a 1,019,197 byte response. A larger stream, or an endless body without auto_decompress, drives the node out of memory.

Impact

A server the client requests can make the client allocate memory proportional to the body it sends, or to its decompressed size, until the node runs out of memory.

Workarounds

Leave auto_decompress disabled (the default). Without it hackney_conn:maybe_decompress_body/2 never inflates the body, which closes the amplification half. The uncapped raw body read has no workaround.

Summary

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.

Details

1. Default trust options. hackney_ssl:check_hostname_opts/1 builds the verify_peer options for every TLS connection: the certifi cacerts, a hostname verify_fun, and {partial_chain, fun hackney_ssl:partial_chain/1}. The callback walks the peer chain and returns {trusted_ca, Cert} for the first certificate whose public key matches a root in the bundled certifi store, which lets OTP accept chains that end in a cross-signed root.

2. Merge keeps the callback. When the caller passes ssl_options, hackney_ssl:merge_ssl_opts/3 merges them over the defaults with the caller's values winning per key. cacerts or cacertfile replace the trust store, and a cacertfile removes the default cacerts, but partial_chain has no counterpart in the caller's options and stays.

3. Validation. OTP consults partial_chain before the configured trust store. A peer chain that carries any publicly trusted root therefore gets that root as its trust anchor, and the pinned cacerts are never consulted. Only the hostname verify_fun still constrains the attacker.

Impact

An attacker positioned between the client and a server pinned to a private CA, holding a publicly trusted certificate for the pinned hostname, can impersonate the server and read or modify the traffic the client sends and receives.

Workarounds

Pass your own {partial_chain, Fun} in ssl_options alongside cacerts or cacertfile. A caller-supplied partial_chain replaces hackney's in the merge, and a callback that returns unknown_ca makes OTP validate against the configured cacerts only.

Configurations

The caller passes cacerts or cacertfile in ssl_options to restrict trust to a private CA, without a partial_chain of its own. Connections that use hackney's default certifi trust store are not affected.

Summary

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.

Details

1. Redirect handling. With follow_redirect set, hackney:request/5 hands a 3xx response to hackney:follow_redirect/10 in src/hackney.erl, which resolves the Location header against the current URL and calls hackney:request/5 again with the caller's options and an empty header list. HTTP/1.1 and HTTP/2 share this path.

2. Host-only comparison. Before the new request, hackney:maybe_strip_auth_on_redirect/3 removes the basic_auth and cookie options when the redirect leaves the current host, unless location_trusted is set. It compared #hackney_url.host of the two URLs.

3. Consequence. A redirect that keeps the hostname but changes the scheme or the port passes the check, so the new request carries the same Authorization and Cookie headers. From https to http they travel in cleartext; to another port they reach a different service on the same host.

Impact

A server that answers a credentialed request with a same-host redirect to plain HTTP exposes the client's Authorization and Cookie headers to anyone on the network path, and a redirect to another port delivers them to whatever service listens there. The captured values can be replayed against the original origin.

Workarounds

Disable follow_redirect and handle the Location header in the application, or pass the credentials as explicit Authorization and Cookie request headers instead of the basic_auth and cookie options. hackney:follow_redirect/10 issues the redirected request with an empty header list, so explicit headers reach the first server only.

Configurations

The request is made with follow_redirect enabled and the basic_auth or cookie option set, over HTTP/1.1 or HTTP/2, without location_trusted. Credentials passed as explicit request headers are not forwarded on redirects and are not affected.

Summary

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.

Details

1. The gate. hackney_url:normalize/2 in src/hackney_url.erl percent-decodes a host that is not already an IP literal and raises invalid_url_host when inet_parse:address/1 accepts the decoded value. This closed the plain percent-encoded IP case.

2. What the connect path accepts. hackney_happy:parse_address/1 removes a surrounding [...] pair before calling inet:parse_address/1, and the resolver treats a trailing dot as the root label. Neither form is accepted by inet_parse:address/1, so [::ffff:127.0.0.1] and 127.0.0.1. pass the gate.

3. Result. A percent-encoded bracketed IPv6 literal such as %5B%3A%3Affff%3A127%2E0%2E0%2E1%5D, or an IPv4 literal with a trailing dot, is not an IP address to a caller's check based on uri_string:parse/1 and inet:parse_address/1, but hackney connects to the address it denotes. The same applies to a Location target when redirects are followed. The fix strips one bracket pair and one trailing dot in ip_candidate/1 before the gate.

Impact

An application that checks user-supplied URLs against an IP allowlist before handing them to hackney can be made to request loopback, link-local metadata and private-network addresses that the allowlist rejects when they are written plainly.

Workarounds

Run the allowlist on the host that hackney_url:normalize/1 returns for the parsed URL, and strip a surrounding bracket pair and a trailing dot from it before the IP check, so the check sees the same address the connect path uses.

Configurations

The application passes URLs that an untrusted party can influence to hackney and relies on its own host allowlist, built on uri_string:parse/1 or inet:parse_address/1, to keep requests away from internal addresses.

Summary

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.

Details

1. Challenge. hackney_http_connect:do_handshake_with_auth/9 in src/hackney_http_connect.erl sends the CONNECT request to the proxy. When the proxy answers 407 and the proxy_auth_fun option is set, it hands the status code and the parsed response headers to hackney_http_connect:handle_proxy_auth/11.

2. Callback result. handle_proxy_auth/11 calls the caller's proxy_auth_fun with those two values. On {ok, AuthHeader} it removes any existing Proxy-Authorization header and appends the binary <<"Proxy-Authorization: ", AuthHeader/binary>> to the header list, then retries the handshake with it.

3. Splitting. The header list is joined with CRLF into the CONNECT request. A CR, LF or NUL byte inside AuthHeader therefore ends the Proxy-Authorization line early and the rest is sent as further header lines. The target host and the request headers go through control-byte checks on this path; the callback result did not. The fix applies the same has_ctl_bytes/1 check to it and returns {error, {proxy_auth_error, invalid_header}}.

Impact

A party who controls what the application's proxy_auth_fun returns, for instance through the challenge headers of a proxy it can influence, can add header lines to the CONNECT request the client sends to its proxy.

Workarounds

Check the value your proxy_auth_fun is about to return for CR, LF and NUL bytes and return {error, Reason} instead when one is present. The callback runs in the application, so the check can be made there.

Configurations

The client connects through an HTTP CONNECT proxy with the proxy_auth_fun option set, and the callback builds its result from data an untrusted party can influence, such as the proxy's 407 challenge headers. Deployments without proxy_auth_fun, or whose callback returns a fixed credential, are not affected.

Summary

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.

Details

1. Unbounded accumulation. hackney:request/5 with a body, and hackney:body/1 after start_response/1, read the response in src/hackney_conn.erl through read_full_body/2, which appends each chunk to a binary accumulator until the body ends. The HTTP/2 and HTTP/3 synchronous paths accumulate stream data the same way. No option caps the size.

2. One-step decompression. With {auto_decompress, true} hackney sends Accept-Encoding: gzip, deflate. Once the body is complete, maybe_decompress_body/2 dispatches on Content-Encoding to decompress_gzip/1 (zlib:gunzip/1) or decompress_deflate/1 (zlib:inflate/2). Both return the whole output at once, so the inflated size is bounded only by the compression ratio. The report measured a 1 MB gzip body inflating to 1 GB on hackney 4.8.4.

Proof of concept

1. Build a gzip stream whose inflated size is 1 GB from a reused 64 KB chunk of zero bytes (deflate with window bits 31, best compression). The stream is about 1 MB on the wire.
2. Start a TCP listener on loopback that accepts one connection, reads the request, and answers HTTP/1.1 200 OK with Content-Encoding: gzip, a Content-Length matching the stream, Connection: close, and the stream as body.
3. From a node running a vulnerable hackney, call hackney:request(get, Url, [], <<>>, [{auto_decompress, true}, with_body]) against that listener.
4. Observe the returned body of 1,048,576,000 bytes and the VM memory growing by about 1.8 GB for a 1,019,197 byte response. A larger stream, or an endless body without auto_decompress, drives the node out of memory.

Impact

A server the client requests can make the client allocate memory proportional to the body it sends, or to its decompressed size, until the node runs out of memory.

Workarounds

Leave auto_decompress disabled (the default). Without it hackney_conn:maybe_decompress_body/2 never inflates the body, which closes the amplification half. The uncapped raw body read has no workaround.

Summary

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.

Details

1. Default trust options. hackney_ssl:check_hostname_opts/1 builds the verify_peer options for every TLS connection: the certifi cacerts, a hostname verify_fun, and {partial_chain, fun hackney_ssl:partial_chain/1}. The callback walks the peer chain and returns {trusted_ca, Cert} for the first certificate whose public key matches a root in the bundled certifi store, which lets OTP accept chains that end in a cross-signed root.

2. Merge keeps the callback. When the caller passes ssl_options, hackney_ssl:merge_ssl_opts/3 merges them over the defaults with the caller's values winning per key. cacerts or cacertfile replace the trust store, and a cacertfile removes the default cacerts, but partial_chain has no counterpart in the caller's options and stays.

3. Validation. OTP consults partial_chain before the configured trust store. A peer chain that carries any publicly trusted root therefore gets that root as its trust anchor, and the pinned cacerts are never consulted. Only the hostname verify_fun still constrains the attacker.

Impact

An attacker positioned between the client and a server pinned to a private CA, holding a publicly trusted certificate for the pinned hostname, can impersonate the server and read or modify the traffic the client sends and receives.

Workarounds

Pass your own {partial_chain, Fun} in ssl_options alongside cacerts or cacertfile. A caller-supplied partial_chain replaces hackney's in the merge, and a callback that returns unknown_ca makes OTP validate against the configured cacerts only.

Configurations

The caller passes cacerts or cacertfile in ssl_options to restrict trust to a private CA, without a partial_chain of its own. Connections that use hackney's default certifi trust store are not affected.

Summary

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.

Details

1. Redirect handling. With follow_redirect set, hackney:request/5 hands a 3xx response to hackney:follow_redirect/10 in src/hackney.erl, which resolves the Location header against the current URL and calls hackney:request/5 again with the caller's options and an empty header list. HTTP/1.1 and HTTP/2 share this path.

2. Host-only comparison. Before the new request, hackney:maybe_strip_auth_on_redirect/3 removes the basic_auth and cookie options when the redirect leaves the current host, unless location_trusted is set. It compared #hackney_url.host of the two URLs.

3. Consequence. A redirect that keeps the hostname but changes the scheme or the port passes the check, so the new request carries the same Authorization and Cookie headers. From https to http they travel in cleartext; to another port they reach a different service on the same host.

Impact

A server that answers a credentialed request with a same-host redirect to plain HTTP exposes the client's Authorization and Cookie headers to anyone on the network path, and a redirect to another port delivers them to whatever service listens there. The captured values can be replayed against the original origin.

Workarounds

Disable follow_redirect and handle the Location header in the application, or pass the credentials as explicit Authorization and Cookie request headers instead of the basic_auth and cookie options. hackney:follow_redirect/10 issues the redirected request with an empty header list, so explicit headers reach the first server only.

Configurations

The request is made with follow_redirect enabled and the basic_auth or cookie option set, over HTTP/1.1 or HTTP/2, without location_trusted. Credentials passed as explicit request headers are not forwarded on redirects and are not affected.

Summary

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.

Details

1. The gate. hackney_url:normalize/2 in src/hackney_url.erl percent-decodes a host that is not already an IP literal and raises invalid_url_host when inet_parse:address/1 accepts the decoded value. This closed the plain percent-encoded IP case.

2. What the connect path accepts. hackney_happy:parse_address/1 removes a surrounding [...] pair before calling inet:parse_address/1, and the resolver treats a trailing dot as the root label. Neither form is accepted by inet_parse:address/1, so [::ffff:127.0.0.1] and 127.0.0.1. pass the gate.

3. Result. A percent-encoded bracketed IPv6 literal such as %5B%3A%3Affff%3A127%2E0%2E0%2E1%5D, or an IPv4 literal with a trailing dot, is not an IP address to a caller's check based on uri_string:parse/1 and inet:parse_address/1, but hackney connects to the address it denotes. The same applies to a Location target when redirects are followed. The fix strips one bracket pair and one trailing dot in ip_candidate/1 before the gate.

Impact

An application that checks user-supplied URLs against an IP allowlist before handing them to hackney can be made to request loopback, link-local metadata and private-network addresses that the allowlist rejects when they are written plainly.

Workarounds

Run the allowlist on the host that hackney_url:normalize/1 returns for the parsed URL, and strip a surrounding bracket pair and a trailing dot from it before the IP check, so the check sees the same address the connect path uses.

Configurations

The application passes URLs that an untrusted party can influence to hackney and relies on its own host allowlist, built on uri_string:parse/1 or inet:parse_address/1, to keep requests away from internal addresses.

Summary

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.

Details

1. Challenge. hackney_http_connect:do_handshake_with_auth/9 in src/hackney_http_connect.erl sends the CONNECT request to the proxy. When the proxy answers 407 and the proxy_auth_fun option is set, it hands the status code and the parsed response headers to hackney_http_connect:handle_proxy_auth/11.

2. Callback result. handle_proxy_auth/11 calls the caller's proxy_auth_fun with those two values. On {ok, AuthHeader} it removes any existing Proxy-Authorization header and appends the binary <<"Proxy-Authorization: ", AuthHeader/binary>> to the header list, then retries the handshake with it.

3. Splitting. The header list is joined with CRLF into the CONNECT request. A CR, LF or NUL byte inside AuthHeader therefore ends the Proxy-Authorization line early and the rest is sent as further header lines. The target host and the request headers go through control-byte checks on this path; the callback result did not. The fix applies the same has_ctl_bytes/1 check to it and returns {error, {proxy_auth_error, invalid_header}}.

Impact

A party who controls what the application's proxy_auth_fun returns, for instance through the challenge headers of a proxy it can influence, can add header lines to the CONNECT request the client sends to its proxy.

Workarounds

Check the value your proxy_auth_fun is about to return for CR, LF and NUL bytes and return {error, Reason} instead when one is present. The callback runs in the application, so the check can be made there.

Configurations

The client connects through an HTTP CONNECT proxy with the proxy_auth_fun option set, and the callback builds its result from data an untrusted party can influence, such as the proxy's 407 challenge headers. Deployments without proxy_auth_fun, or whose callback returns a fixed credential, are not affected.

Summary

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.

Details

1. Unbounded accumulation. hackney:request/5 with a body, and hackney:body/1 after start_response/1, read the response in src/hackney_conn.erl through read_full_body/2, which appends each chunk to a binary accumulator until the body ends. The HTTP/2 and HTTP/3 synchronous paths accumulate stream data the same way. No option caps the size.

2. One-step decompression. With {auto_decompress, true} hackney sends Accept-Encoding: gzip, deflate. Once the body is complete, maybe_decompress_body/2 dispatches on Content-Encoding to decompress_gzip/1 (zlib:gunzip/1) or decompress_deflate/1 (zlib:inflate/2). Both return the whole output at once, so the inflated size is bounded only by the compression ratio. The report measured a 1 MB gzip body inflating to 1 GB on hackney 4.8.4.

Proof of concept

1. Build a gzip stream whose inflated size is 1 GB from a reused 64 KB chunk of zero bytes (deflate with window bits 31, best compression). The stream is about 1 MB on the wire.
2. Start a TCP listener on loopback that accepts one connection, reads the request, and answers HTTP/1.1 200 OK with Content-Encoding: gzip, a Content-Length matching the stream, Connection: close, and the stream as body.
3. From a node running a vulnerable hackney, call hackney:request(get, Url, [], <<>>, [{auto_decompress, true}, with_body]) against that listener.
4. Observe the returned body of 1,048,576,000 bytes and the VM memory growing by about 1.8 GB for a 1,019,197 byte response. A larger stream, or an endless body without auto_decompress, drives the node out of memory.

Impact

A server the client requests can make the client allocate memory proportional to the body it sends, or to its decompressed size, until the node runs out of memory.

Workarounds

Leave auto_decompress disabled (the default). Without it hackney_conn:maybe_decompress_body/2 never inflates the body, which closes the amplification half. The uncapped raw body read has no workaround.

Summary

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.

Details

1. Default trust options. hackney_ssl:check_hostname_opts/1 builds the verify_peer options for every TLS connection: the certifi cacerts, a hostname verify_fun, and {partial_chain, fun hackney_ssl:partial_chain/1}. The callback walks the peer chain and returns {trusted_ca, Cert} for the first certificate whose public key matches a root in the bundled certifi store, which lets OTP accept chains that end in a cross-signed root.

2. Merge keeps the callback. When the caller passes ssl_options, hackney_ssl:merge_ssl_opts/3 merges them over the defaults with the caller's values winning per key. cacerts or cacertfile replace the trust store, and a cacertfile removes the default cacerts, but partial_chain has no counterpart in the caller's options and stays.

3. Validation. OTP consults partial_chain before the configured trust store. A peer chain that carries any publicly trusted root therefore gets that root as its trust anchor, and the pinned cacerts are never consulted. Only the hostname verify_fun still constrains the attacker.

Impact

An attacker positioned between the client and a server pinned to a private CA, holding a publicly trusted certificate for the pinned hostname, can impersonate the server and read or modify the traffic the client sends and receives.

Workarounds

Pass your own {partial_chain, Fun} in ssl_options alongside cacerts or cacertfile. A caller-supplied partial_chain replaces hackney's in the merge, and a callback that returns unknown_ca makes OTP validate against the configured cacerts only.

Configurations

The caller passes cacerts or cacertfile in ssl_options to restrict trust to a private CA, without a partial_chain of its own. Connections that use hackney's default certifi trust store are not affected.

Summary

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.

Details

1. Redirect handling. With follow_redirect set, hackney:request/5 hands a 3xx response to hackney:follow_redirect/10 in src/hackney.erl, which resolves the Location header against the current URL and calls hackney:request/5 again with the caller's options and an empty header list. HTTP/1.1 and HTTP/2 share this path.

2. Host-only comparison. Before the new request, hackney:maybe_strip_auth_on_redirect/3 removes the basic_auth and cookie options when the redirect leaves the current host, unless location_trusted is set. It compared #hackney_url.host of the two URLs.

3. Consequence. A redirect that keeps the hostname but changes the scheme or the port passes the check, so the new request carries the same Authorization and Cookie headers. From https to http they travel in cleartext; to another port they reach a different service on the same host.

Impact

A server that answers a credentialed request with a same-host redirect to plain HTTP exposes the client's Authorization and Cookie headers to anyone on the network path, and a redirect to another port delivers them to whatever service listens there. The captured values can be replayed against the original origin.

Workarounds

Disable follow_redirect and handle the Location header in the application, or pass the credentials as explicit Authorization and Cookie request headers instead of the basic_auth and cookie options. hackney:follow_redirect/10 issues the redirected request with an empty header list, so explicit headers reach the first server only.

Configurations

The request is made with follow_redirect enabled and the basic_auth or cookie option set, over HTTP/1.1 or HTTP/2, without location_trusted. Credentials passed as explicit request headers are not forwarded on redirects and are not affected.

Summary

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.

Details

1. The gate. hackney_url:normalize/2 in src/hackney_url.erl percent-decodes a host that is not already an IP literal and raises invalid_url_host when inet_parse:address/1 accepts the decoded value. This closed the plain percent-encoded IP case.

2. What the connect path accepts. hackney_happy:parse_address/1 removes a surrounding [...] pair before calling inet:parse_address/1, and the resolver treats a trailing dot as the root label. Neither form is accepted by inet_parse:address/1, so [::ffff:127.0.0.1] and 127.0.0.1. pass the gate.

3. Result. A percent-encoded bracketed IPv6 literal such as %5B%3A%3Affff%3A127%2E0%2E0%2E1%5D, or an IPv4 literal with a trailing dot, is not an IP address to a caller's check based on uri_string:parse/1 and inet:parse_address/1, but hackney connects to the address it denotes. The same applies to a Location target when redirects are followed. The fix strips one bracket pair and one trailing dot in ip_candidate/1 before the gate.

Impact

An application that checks user-supplied URLs against an IP allowlist before handing them to hackney can be made to request loopback, link-local metadata and private-network addresses that the allowlist rejects when they are written plainly.

Workarounds

Run the allowlist on the host that hackney_url:normalize/1 returns for the parsed URL, and strip a surrounding bracket pair and a trailing dot from it before the IP check, so the check sees the same address the connect path uses.

Configurations

The application passes URLs that an untrusted party can influence to hackney and relies on its own host allowlist, built on uri_string:parse/1 or inet:parse_address/1, to keep requests away from internal addresses.

Summary

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.

Details

1. Challenge. hackney_http_connect:do_handshake_with_auth/9 in src/hackney_http_connect.erl sends the CONNECT request to the proxy. When the proxy answers 407 and the proxy_auth_fun option is set, it hands the status code and the parsed response headers to hackney_http_connect:handle_proxy_auth/11.

2. Callback result. handle_proxy_auth/11 calls the caller's proxy_auth_fun with those two values. On {ok, AuthHeader} it removes any existing Proxy-Authorization header and appends the binary <<"Proxy-Authorization: ", AuthHeader/binary>> to the header list, then retries the handshake with it.

3. Splitting. The header list is joined with CRLF into the CONNECT request. A CR, LF or NUL byte inside AuthHeader therefore ends the Proxy-Authorization line early and the rest is sent as further header lines. The target host and the request headers go through control-byte checks on this path; the callback result did not. The fix applies the same has_ctl_bytes/1 check to it and returns {error, {proxy_auth_error, invalid_header}}.

Impact

A party who controls what the application's proxy_auth_fun returns, for instance through the challenge headers of a proxy it can influence, can add header lines to the CONNECT request the client sends to its proxy.

Workarounds

Check the value your proxy_auth_fun is about to return for CR, LF and NUL bytes and return {error, Reason} instead when one is present. The callback runs in the application, so the check can be made there.

Configurations

The client connects through an HTTP CONNECT proxy with the proxy_auth_fun option set, and the callback builds its result from data an untrusted party can influence, such as the proxy's 407 challenge headers. Deployments without proxy_auth_fun, or whose callback returns a fixed credential, are not affected.

Summary

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.

Details

1. Unbounded accumulation. hackney:request/5 with a body, and hackney:body/1 after start_response/1, read the response in src/hackney_conn.erl through read_full_body/2, which appends each chunk to a binary accumulator until the body ends. The HTTP/2 and HTTP/3 synchronous paths accumulate stream data the same way. No option caps the size.

2. One-step decompression. With {auto_decompress, true} hackney sends Accept-Encoding: gzip, deflate. Once the body is complete, maybe_decompress_body/2 dispatches on Content-Encoding to decompress_gzip/1 (zlib:gunzip/1) or decompress_deflate/1 (zlib:inflate/2). Both return the whole output at once, so the inflated size is bounded only by the compression ratio. The report measured a 1 MB gzip body inflating to 1 GB on hackney 4.8.4.

Proof of concept

1. Build a gzip stream whose inflated size is 1 GB from a reused 64 KB chunk of zero bytes (deflate with window bits 31, best compression). The stream is about 1 MB on the wire.
2. Start a TCP listener on loopback that accepts one connection, reads the request, and answers HTTP/1.1 200 OK with Content-Encoding: gzip, a Content-Length matching the stream, Connection: close, and the stream as body.
3. From a node running a vulnerable hackney, call hackney:request(get, Url, [], <<>>, [{auto_decompress, true}, with_body]) against that listener.
4. Observe the returned body of 1,048,576,000 bytes and the VM memory growing by about 1.8 GB for a 1,019,197 byte response. A larger stream, or an endless body without auto_decompress, drives the node out of memory.

Impact

A server the client requests can make the client allocate memory proportional to the body it sends, or to its decompressed size, until the node runs out of memory.

Workarounds

Leave auto_decompress disabled (the default). Without it hackney_conn:maybe_decompress_body/2 never inflates the body, which closes the amplification half. The uncapped raw body read has no workaround.

Summary

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.

Details

1. Default trust options. hackney_ssl:check_hostname_opts/1 builds the verify_peer options for every TLS connection: the certifi cacerts, a hostname verify_fun, and {partial_chain, fun hackney_ssl:partial_chain/1}. The callback walks the peer chain and returns {trusted_ca, Cert} for the first certificate whose public key matches a root in the bundled certifi store, which lets OTP accept chains that end in a cross-signed root.

2. Merge keeps the callback. When the caller passes ssl_options, hackney_ssl:merge_ssl_opts/3 merges them over the defaults with the caller's values winning per key. cacerts or cacertfile replace the trust store, and a cacertfile removes the default cacerts, but partial_chain has no counterpart in the caller's options and stays.

3. Validation. OTP consults partial_chain before the configured trust store. A peer chain that carries any publicly trusted root therefore gets that root as its trust anchor, and the pinned cacerts are never consulted. Only the hostname verify_fun still constrains the attacker.

Impact

An attacker positioned between the client and a server pinned to a private CA, holding a publicly trusted certificate for the pinned hostname, can impersonate the server and read or modify the traffic the client sends and receives.

Workarounds

Pass your own {partial_chain, Fun} in ssl_options alongside cacerts or cacertfile. A caller-supplied partial_chain replaces hackney's in the merge, and a callback that returns unknown_ca makes OTP validate against the configured cacerts only.

Configurations

The caller passes cacerts or cacertfile in ssl_options to restrict trust to a private CA, without a partial_chain of its own. Connections that use hackney's default certifi trust store are not affected.

Summary

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.

Details

1. Redirect handling. With follow_redirect set, hackney:request/5 hands a 3xx response to hackney:follow_redirect/10 in src/hackney.erl, which resolves the Location header against the current URL and calls hackney:request/5 again with the caller's options and an empty header list. HTTP/1.1 and HTTP/2 share this path.

2. Host-only comparison. Before the new request, hackney:maybe_strip_auth_on_redirect/3 removes the basic_auth and cookie options when the redirect leaves the current host, unless location_trusted is set. It compared #hackney_url.host of the two URLs.

3. Consequence. A redirect that keeps the hostname but changes the scheme or the port passes the check, so the new request carries the same Authorization and Cookie headers. From https to http they travel in cleartext; to another port they reach a different service on the same host.

Impact

A server that answers a credentialed request with a same-host redirect to plain HTTP exposes the client's Authorization and Cookie headers to anyone on the network path, and a redirect to another port delivers them to whatever service listens there. The captured values can be replayed against the original origin.

Workarounds

Disable follow_redirect and handle the Location header in the application, or pass the credentials as explicit Authorization and Cookie request headers instead of the basic_auth and cookie options. hackney:follow_redirect/10 issues the redirected request with an empty header list, so explicit headers reach the first server only.

Configurations

The request is made with follow_redirect enabled and the basic_auth or cookie option set, over HTTP/1.1 or HTTP/2, without location_trusted. Credentials passed as explicit request headers are not forwarded on redirects and are not affected.

Summary

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.

Details

1. The gate. hackney_url:normalize/2 in src/hackney_url.erl percent-decodes a host that is not already an IP literal and raises invalid_url_host when inet_parse:address/1 accepts the decoded value. This closed the plain percent-encoded IP case.

2. What the connect path accepts. hackney_happy:parse_address/1 removes a surrounding [...] pair before calling inet:parse_address/1, and the resolver treats a trailing dot as the root label. Neither form is accepted by inet_parse:address/1, so [::ffff:127.0.0.1] and 127.0.0.1. pass the gate.

3. Result. A percent-encoded bracketed IPv6 literal such as %5B%3A%3Affff%3A127%2E0%2E0%2E1%5D, or an IPv4 literal with a trailing dot, is not an IP address to a caller's check based on uri_string:parse/1 and inet:parse_address/1, but hackney connects to the address it denotes. The same applies to a Location target when redirects are followed. The fix strips one bracket pair and one trailing dot in ip_candidate/1 before the gate.

Impact

An application that checks user-supplied URLs against an IP allowlist before handing them to hackney can be made to request loopback, link-local metadata and private-network addresses that the allowlist rejects when they are written plainly.

Workarounds

Run the allowlist on the host that hackney_url:normalize/1 returns for the parsed URL, and strip a surrounding bracket pair and a trailing dot from it before the IP check, so the check sees the same address the connect path uses.

Configurations

The application passes URLs that an untrusted party can influence to hackney and relies on its own host allowlist, built on uri_string:parse/1 or inet:parse_address/1, to keep requests away from internal addresses.

Summary

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.

Details

1. Challenge. hackney_http_connect:do_handshake_with_auth/9 in src/hackney_http_connect.erl sends the CONNECT request to the proxy. When the proxy answers 407 and the proxy_auth_fun option is set, it hands the status code and the parsed response headers to hackney_http_connect:handle_proxy_auth/11.

2. Callback result. handle_proxy_auth/11 calls the caller's proxy_auth_fun with those two values. On {ok, AuthHeader} it removes any existing Proxy-Authorization header and appends the binary <<"Proxy-Authorization: ", AuthHeader/binary>> to the header list, then retries the handshake with it.

3. Splitting. The header list is joined with CRLF into the CONNECT request. A CR, LF or NUL byte inside AuthHeader therefore ends the Proxy-Authorization line early and the rest is sent as further header lines. The target host and the request headers go through control-byte checks on this path; the callback result did not. The fix applies the same has_ctl_bytes/1 check to it and returns {error, {proxy_auth_error, invalid_header}}.

Impact

A party who controls what the application's proxy_auth_fun returns, for instance through the challenge headers of a proxy it can influence, can add header lines to the CONNECT request the client sends to its proxy.

Workarounds

Check the value your proxy_auth_fun is about to return for CR, LF and NUL bytes and return {error, Reason} instead when one is present. The callback runs in the application, so the check can be made there.

Configurations

The client connects through an HTTP CONNECT proxy with the proxy_auth_fun option set, and the callback builds its result from data an untrusted party can influence, such as the proxy's 407 challenge headers. Deployments without proxy_auth_fun, or whose callback returns a fixed credential, are not affected.

Summary

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.

Details

1. Unbounded accumulation. hackney:request/5 with a body, and hackney:body/1 after start_response/1, read the response in src/hackney_conn.erl through read_full_body/2, which appends each chunk to a binary accumulator until the body ends. The HTTP/2 and HTTP/3 synchronous paths accumulate stream data the same way. No option caps the size.

2. One-step decompression. With {auto_decompress, true} hackney sends Accept-Encoding: gzip, deflate. Once the body is complete, maybe_decompress_body/2 dispatches on Content-Encoding to decompress_gzip/1 (zlib:gunzip/1) or decompress_deflate/1 (zlib:inflate/2). Both return the whole output at once, so the inflated size is bounded only by the compression ratio. The report measured a 1 MB gzip body inflating to 1 GB on hackney 4.8.4.

Proof of concept

1. Build a gzip stream whose inflated size is 1 GB from a reused 64 KB chunk of zero bytes (deflate with window bits 31, best compression). The stream is about 1 MB on the wire.
2. Start a TCP listener on loopback that accepts one connection, reads the request, and answers HTTP/1.1 200 OK with Content-Encoding: gzip, a Content-Length matching the stream, Connection: close, and the stream as body.
3. From a node running a vulnerable hackney, call hackney:request(get, Url, [], <<>>, [{auto_decompress, true}, with_body]) against that listener.
4. Observe the returned body of 1,048,576,000 bytes and the VM memory growing by about 1.8 GB for a 1,019,197 byte response. A larger stream, or an endless body without auto_decompress, drives the node out of memory.

Impact

A server the client requests can make the client allocate memory proportional to the body it sends, or to its decompressed size, until the node runs out of memory.

Workarounds

Leave auto_decompress disabled (the default). Without it hackney_conn:maybe_decompress_body/2 never inflates the body, which closes the amplification half. The uncapped raw body read has no workaround.

Summary

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.

Details

1. Default trust options. hackney_ssl:check_hostname_opts/1 builds the verify_peer options for every TLS connection: the certifi cacerts, a hostname verify_fun, and {partial_chain, fun hackney_ssl:partial_chain/1}. The callback walks the peer chain and returns {trusted_ca, Cert} for the first certificate whose public key matches a root in the bundled certifi store, which lets OTP accept chains that end in a cross-signed root.

2. Merge keeps the callback. When the caller passes ssl_options, hackney_ssl:merge_ssl_opts/3 merges them over the defaults with the caller's values winning per key. cacerts or cacertfile replace the trust store, and a cacertfile removes the default cacerts, but partial_chain has no counterpart in the caller's options and stays.

3. Validation. OTP consults partial_chain before the configured trust store. A peer chain that carries any publicly trusted root therefore gets that root as its trust anchor, and the pinned cacerts are never consulted. Only the hostname verify_fun still constrains the attacker.

Impact

An attacker positioned between the client and a server pinned to a private CA, holding a publicly trusted certificate for the pinned hostname, can impersonate the server and read or modify the traffic the client sends and receives.

Workarounds

Pass your own {partial_chain, Fun} in ssl_options alongside cacerts or cacertfile. A caller-supplied partial_chain replaces hackney's in the merge, and a callback that returns unknown_ca makes OTP validate against the configured cacerts only.

Configurations

The caller passes cacerts or cacertfile in ssl_options to restrict trust to a private CA, without a partial_chain of its own. Connections that use hackney's default certifi trust store are not affected.

Summary

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.

Details

1. Redirect handling. With follow_redirect set, hackney:request/5 hands a 3xx response to hackney:follow_redirect/10 in src/hackney.erl, which resolves the Location header against the current URL and calls hackney:request/5 again with the caller's options and an empty header list. HTTP/1.1 and HTTP/2 share this path.

2. Host-only comparison. Before the new request, hackney:maybe_strip_auth_on_redirect/3 removes the basic_auth and cookie options when the redirect leaves the current host, unless location_trusted is set. It compared #hackney_url.host of the two URLs.

3. Consequence. A redirect that keeps the hostname but changes the scheme or the port passes the check, so the new request carries the same Authorization and Cookie headers. From https to http they travel in cleartext; to another port they reach a different service on the same host.

Impact

A server that answers a credentialed request with a same-host redirect to plain HTTP exposes the client's Authorization and Cookie headers to anyone on the network path, and a redirect to another port delivers them to whatever service listens there. The captured values can be replayed against the original origin.

Workarounds

Disable follow_redirect and handle the Location header in the application, or pass the credentials as explicit Authorization and Cookie request headers instead of the basic_auth and cookie options. hackney:follow_redirect/10 issues the redirected request with an empty header list, so explicit headers reach the first server only.

Configurations

The request is made with follow_redirect enabled and the basic_auth or cookie option set, over HTTP/1.1 or HTTP/2, without location_trusted. Credentials passed as explicit request headers are not forwarded on redirects and are not affected.

Summary

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.

Details

1. The gate. hackney_url:normalize/2 in src/hackney_url.erl percent-decodes a host that is not already an IP literal and raises invalid_url_host when inet_parse:address/1 accepts the decoded value. This closed the plain percent-encoded IP case.

2. What the connect path accepts. hackney_happy:parse_address/1 removes a surrounding [...] pair before calling inet:parse_address/1, and the resolver treats a trailing dot as the root label. Neither form is accepted by inet_parse:address/1, so [::ffff:127.0.0.1] and 127.0.0.1. pass the gate.

3. Result. A percent-encoded bracketed IPv6 literal such as %5B%3A%3Affff%3A127%2E0%2E0%2E1%5D, or an IPv4 literal with a trailing dot, is not an IP address to a caller's check based on uri_string:parse/1 and inet:parse_address/1, but hackney connects to the address it denotes. The same applies to a Location target when redirects are followed. The fix strips one bracket pair and one trailing dot in ip_candidate/1 before the gate.

Impact

An application that checks user-supplied URLs against an IP allowlist before handing them to hackney can be made to request loopback, link-local metadata and private-network addresses that the allowlist rejects when they are written plainly.

Workarounds

Run the allowlist on the host that hackney_url:normalize/1 returns for the parsed URL, and strip a surrounding bracket pair and a trailing dot from it before the IP check, so the check sees the same address the connect path uses.

Configurations

The application passes URLs that an untrusted party can influence to hackney and relies on its own host allowlist, built on uri_string:parse/1 or inet:parse_address/1, to keep requests away from internal addresses.

Summary

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.

Details

1. Challenge. hackney_http_connect:do_handshake_with_auth/9 in src/hackney_http_connect.erl sends the CONNECT request to the proxy. When the proxy answers 407 and the proxy_auth_fun option is set, it hands the status code and the parsed response headers to hackney_http_connect:handle_proxy_auth/11.

2. Callback result. handle_proxy_auth/11 calls the caller's proxy_auth_fun with those two values. On {ok, AuthHeader} it removes any existing Proxy-Authorization header and appends the binary <<"Proxy-Authorization: ", AuthHeader/binary>> to the header list, then retries the handshake with it.

3. Splitting. The header list is joined with CRLF into the CONNECT request. A CR, LF or NUL byte inside AuthHeader therefore ends the Proxy-Authorization line early and the rest is sent as further header lines. The target host and the request headers go through control-byte checks on this path; the callback result did not. The fix applies the same has_ctl_bytes/1 check to it and returns {error, {proxy_auth_error, invalid_header}}.

Impact

A party who controls what the application's proxy_auth_fun returns, for instance through the challenge headers of a proxy it can influence, can add header lines to the CONNECT request the client sends to its proxy.

Workarounds

Check the value your proxy_auth_fun is about to return for CR, LF and NUL bytes and return {error, Reason} instead when one is present. The callback runs in the application, so the check can be made there.

Configurations

The client connects through an HTTP CONNECT proxy with the proxy_auth_fun option set, and the callback builds its result from data an untrusted party can influence, such as the proxy's 407 challenge headers. Deployments without proxy_auth_fun, or whose callback returns a fixed credential, are not affected.

Summary

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.

Details

1. Unbounded accumulation. hackney:request/5 with a body, and hackney:body/1 after start_response/1, read the response in src/hackney_conn.erl through read_full_body/2, which appends each chunk to a binary accumulator until the body ends. The HTTP/2 and HTTP/3 synchronous paths accumulate stream data the same way. No option caps the size.

2. One-step decompression. With {auto_decompress, true} hackney sends Accept-Encoding: gzip, deflate. Once the body is complete, maybe_decompress_body/2 dispatches on Content-Encoding to decompress_gzip/1 (zlib:gunzip/1) or decompress_deflate/1 (zlib:inflate/2). Both return the whole output at once, so the inflated size is bounded only by the compression ratio. The report measured a 1 MB gzip body inflating to 1 GB on hackney 4.8.4.

Proof of concept

1. Build a gzip stream whose inflated size is 1 GB from a reused 64 KB chunk of zero bytes (deflate with window bits 31, best compression). The stream is about 1 MB on the wire.
2. Start a TCP listener on loopback that accepts one connection, reads the request, and answers HTTP/1.1 200 OK with Content-Encoding: gzip, a Content-Length matching the stream, Connection: close, and the stream as body.
3. From a node running a vulnerable hackney, call hackney:request(get, Url, [], <<>>, [{auto_decompress, true}, with_body]) against that listener.
4. Observe the returned body of 1,048,576,000 bytes and the VM memory growing by about 1.8 GB for a 1,019,197 byte response. A larger stream, or an endless body without auto_decompress, drives the node out of memory.

Impact

A server the client requests can make the client allocate memory proportional to the body it sends, or to its decompressed size, until the node runs out of memory.

Workarounds

Leave auto_decompress disabled (the default). Without it hackney_conn:maybe_decompress_body/2 never inflates the body, which closes the amplification half. The uncapped raw body read has no workaround.

Summary

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.

Details

1. Default trust options. hackney_ssl:check_hostname_opts/1 builds the verify_peer options for every TLS connection: the certifi cacerts, a hostname verify_fun, and {partial_chain, fun hackney_ssl:partial_chain/1}. The callback walks the peer chain and returns {trusted_ca, Cert} for the first certificate whose public key matches a root in the bundled certifi store, which lets OTP accept chains that end in a cross-signed root.

2. Merge keeps the callback. When the caller passes ssl_options, hackney_ssl:merge_ssl_opts/3 merges them over the defaults with the caller's values winning per key. cacerts or cacertfile replace the trust store, and a cacertfile removes the default cacerts, but partial_chain has no counterpart in the caller's options and stays.

3. Validation. OTP consults partial_chain before the configured trust store. A peer chain that carries any publicly trusted root therefore gets that root as its trust anchor, and the pinned cacerts are never consulted. Only the hostname verify_fun still constrains the attacker.

Impact

An attacker positioned between the client and a server pinned to a private CA, holding a publicly trusted certificate for the pinned hostname, can impersonate the server and read or modify the traffic the client sends and receives.

Workarounds

Pass your own {partial_chain, Fun} in ssl_options alongside cacerts or cacertfile. A caller-supplied partial_chain replaces hackney's in the merge, and a callback that returns unknown_ca makes OTP validate against the configured cacerts only.

Configurations

The caller passes cacerts or cacertfile in ssl_options to restrict trust to a private CA, without a partial_chain of its own. Connections that use hackney's default certifi trust store are not affected.

Summary

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.

Details

1. Redirect handling. With follow_redirect set, hackney:request/5 hands a 3xx response to hackney:follow_redirect/10 in src/hackney.erl, which resolves the Location header against the current URL and calls hackney:request/5 again with the caller's options and an empty header list. HTTP/1.1 and HTTP/2 share this path.

2. Host-only comparison. Before the new request, hackney:maybe_strip_auth_on_redirect/3 removes the basic_auth and cookie options when the redirect leaves the current host, unless location_trusted is set. It compared #hackney_url.host of the two URLs.

3. Consequence. A redirect that keeps the hostname but changes the scheme or the port passes the check, so the new request carries the same Authorization and Cookie headers. From https to http they travel in cleartext; to another port they reach a different service on the same host.

Impact

A server that answers a credentialed request with a same-host redirect to plain HTTP exposes the client's Authorization and Cookie headers to anyone on the network path, and a redirect to another port delivers them to whatever service listens there. The captured values can be replayed against the original origin.

Workarounds

Disable follow_redirect and handle the Location header in the application, or pass the credentials as explicit Authorization and Cookie request headers instead of the basic_auth and cookie options. hackney:follow_redirect/10 issues the redirected request with an empty header list, so explicit headers reach the first server only.

Configurations

The request is made with follow_redirect enabled and the basic_auth or cookie option set, over HTTP/1.1 or HTTP/2, without location_trusted. Credentials passed as explicit request headers are not forwarded on redirects and are not affected.

Summary

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.

Details

1. The gate. hackney_url:normalize/2 in src/hackney_url.erl percent-decodes a host that is not already an IP literal and raises invalid_url_host when inet_parse:address/1 accepts the decoded value. This closed the plain percent-encoded IP case.

2. What the connect path accepts. hackney_happy:parse_address/1 removes a surrounding [...] pair before calling inet:parse_address/1, and the resolver treats a trailing dot as the root label. Neither form is accepted by inet_parse:address/1, so [::ffff:127.0.0.1] and 127.0.0.1. pass the gate.

3. Result. A percent-encoded bracketed IPv6 literal such as %5B%3A%3Affff%3A127%2E0%2E0%2E1%5D, or an IPv4 literal with a trailing dot, is not an IP address to a caller's check based on uri_string:parse/1 and inet:parse_address/1, but hackney connects to the address it denotes. The same applies to a Location target when redirects are followed. The fix strips one bracket pair and one trailing dot in ip_candidate/1 before the gate.

Impact

An application that checks user-supplied URLs against an IP allowlist before handing them to hackney can be made to request loopback, link-local metadata and private-network addresses that the allowlist rejects when they are written plainly.

Workarounds

Run the allowlist on the host that hackney_url:normalize/1 returns for the parsed URL, and strip a surrounding bracket pair and a trailing dot from it before the IP check, so the check sees the same address the connect path uses.

Configurations

The application passes URLs that an untrusted party can influence to hackney and relies on its own host allowlist, built on uri_string:parse/1 or inet:parse_address/1, to keep requests away from internal addresses.

Summary

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.

Details

1. Challenge. hackney_http_connect:do_handshake_with_auth/9 in src/hackney_http_connect.erl sends the CONNECT request to the proxy. When the proxy answers 407 and the proxy_auth_fun option is set, it hands the status code and the parsed response headers to hackney_http_connect:handle_proxy_auth/11.

2. Callback result. handle_proxy_auth/11 calls the caller's proxy_auth_fun with those two values. On {ok, AuthHeader} it removes any existing Proxy-Authorization header and appends the binary <<"Proxy-Authorization: ", AuthHeader/binary>> to the header list, then retries the handshake with it.

3. Splitting. The header list is joined with CRLF into the CONNECT request. A CR, LF or NUL byte inside AuthHeader therefore ends the Proxy-Authorization line early and the rest is sent as further header lines. The target host and the request headers go through control-byte checks on this path; the callback result did not. The fix applies the same has_ctl_bytes/1 check to it and returns {error, {proxy_auth_error, invalid_header}}.

Impact

A party who controls what the application's proxy_auth_fun returns, for instance through the challenge headers of a proxy it can influence, can add header lines to the CONNECT request the client sends to its proxy.

Workarounds

Check the value your proxy_auth_fun is about to return for CR, LF and NUL bytes and return {error, Reason} instead when one is present. The callback runs in the application, so the check can be made there.

Configurations

The client connects through an HTTP CONNECT proxy with the proxy_auth_fun option set, and the callback builds its result from data an untrusted party can influence, such as the proxy's 407 challenge headers. Deployments without proxy_auth_fun, or whose callback returns a fixed credential, are not affected.

Summary

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.

Details

1. Unbounded accumulation. hackney:request/5 with a body, and hackney:body/1 after start_response/1, read the response in src/hackney_conn.erl through read_full_body/2, which appends each chunk to a binary accumulator until the body ends. The HTTP/2 and HTTP/3 synchronous paths accumulate stream data the same way. No option caps the size.

2. One-step decompression. With {auto_decompress, true} hackney sends Accept-Encoding: gzip, deflate. Once the body is complete, maybe_decompress_body/2 dispatches on Content-Encoding to decompress_gzip/1 (zlib:gunzip/1) or decompress_deflate/1 (zlib:inflate/2). Both return the whole output at once, so the inflated size is bounded only by the compression ratio. The report measured a 1 MB gzip body inflating to 1 GB on hackney 4.8.4.

Proof of concept

1. Build a gzip stream whose inflated size is 1 GB from a reused 64 KB chunk of zero bytes (deflate with window bits 31, best compression). The stream is about 1 MB on the wire.
2. Start a TCP listener on loopback that accepts one connection, reads the request, and answers HTTP/1.1 200 OK with Content-Encoding: gzip, a Content-Length matching the stream, Connection: close, and the stream as body.
3. From a node running a vulnerable hackney, call hackney:request(get, Url, [], <<>>, [{auto_decompress, true}, with_body]) against that listener.
4. Observe the returned body of 1,048,576,000 bytes and the VM memory growing by about 1.8 GB for a 1,019,197 byte response. A larger stream, or an endless body without auto_decompress, drives the node out of memory.

Impact

A server the client requests can make the client allocate memory proportional to the body it sends, or to its decompressed size, until the node runs out of memory.

Workarounds

Leave auto_decompress disabled (the default). Without it hackney_conn:maybe_decompress_body/2 never inflates the body, which closes the amplification half. The uncapped raw body read has no workaround.

Summary

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.

Details

1. Default trust options. hackney_ssl:check_hostname_opts/1 builds the verify_peer options for every TLS connection: the certifi cacerts, a hostname verify_fun, and {partial_chain, fun hackney_ssl:partial_chain/1}. The callback walks the peer chain and returns {trusted_ca, Cert} for the first certificate whose public key matches a root in the bundled certifi store, which lets OTP accept chains that end in a cross-signed root.

2. Merge keeps the callback. When the caller passes ssl_options, hackney_ssl:merge_ssl_opts/3 merges them over the defaults with the caller's values winning per key. cacerts or cacertfile replace the trust store, and a cacertfile removes the default cacerts, but partial_chain has no counterpart in the caller's options and stays.

3. Validation. OTP consults partial_chain before the configured trust store. A peer chain that carries any publicly trusted root therefore gets that root as its trust anchor, and the pinned cacerts are never consulted. Only the hostname verify_fun still constrains the attacker.

Impact

An attacker positioned between the client and a server pinned to a private CA, holding a publicly trusted certificate for the pinned hostname, can impersonate the server and read or modify the traffic the client sends and receives.

Workarounds

Pass your own {partial_chain, Fun} in ssl_options alongside cacerts or cacertfile. A caller-supplied partial_chain replaces hackney's in the merge, and a callback that returns unknown_ca makes OTP validate against the configured cacerts only.

Configurations

The caller passes cacerts or cacertfile in ssl_options to restrict trust to a private CA, without a partial_chain of its own. Connections that use hackney's default certifi trust store are not affected.

Summary

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.

Details

1. Redirect handling. With follow_redirect set, hackney:request/5 hands a 3xx response to hackney:follow_redirect/10 in src/hackney.erl, which resolves the Location header against the current URL and calls hackney:request/5 again with the caller's options and an empty header list. HTTP/1.1 and HTTP/2 share this path.

2. Host-only comparison. Before the new request, hackney:maybe_strip_auth_on_redirect/3 removes the basic_auth and cookie options when the redirect leaves the current host, unless location_trusted is set. It compared #hackney_url.host of the two URLs.

3. Consequence. A redirect that keeps the hostname but changes the scheme or the port passes the check, so the new request carries the same Authorization and Cookie headers. From https to http they travel in cleartext; to another port they reach a different service on the same host.

Impact

A server that answers a credentialed request with a same-host redirect to plain HTTP exposes the client's Authorization and Cookie headers to anyone on the network path, and a redirect to another port delivers them to whatever service listens there. The captured values can be replayed against the original origin.

Workarounds

Disable follow_redirect and handle the Location header in the application, or pass the credentials as explicit Authorization and Cookie request headers instead of the basic_auth and cookie options. hackney:follow_redirect/10 issues the redirected request with an empty header list, so explicit headers reach the first server only.

Configurations

The request is made with follow_redirect enabled and the basic_auth or cookie option set, over HTTP/1.1 or HTTP/2, without location_trusted. Credentials passed as explicit request headers are not forwarded on redirects and are not affected.

Summary

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.

Details

1. The gate. hackney_url:normalize/2 in src/hackney_url.erl percent-decodes a host that is not already an IP literal and raises invalid_url_host when inet_parse:address/1 accepts the decoded value. This closed the plain percent-encoded IP case.

2. What the connect path accepts. hackney_happy:parse_address/1 removes a surrounding [...] pair before calling inet:parse_address/1, and the resolver treats a trailing dot as the root label. Neither form is accepted by inet_parse:address/1, so [::ffff:127.0.0.1] and 127.0.0.1. pass the gate.

3. Result. A percent-encoded bracketed IPv6 literal such as %5B%3A%3Affff%3A127%2E0%2E0%2E1%5D, or an IPv4 literal with a trailing dot, is not an IP address to a caller's check based on uri_string:parse/1 and inet:parse_address/1, but hackney connects to the address it denotes. The same applies to a Location target when redirects are followed. The fix strips one bracket pair and one trailing dot in ip_candidate/1 before the gate.

Impact

An application that checks user-supplied URLs against an IP allowlist before handing them to hackney can be made to request loopback, link-local metadata and private-network addresses that the allowlist rejects when they are written plainly.

Workarounds

Run the allowlist on the host that hackney_url:normalize/1 returns for the parsed URL, and strip a surrounding bracket pair and a trailing dot from it before the IP check, so the check sees the same address the connect path uses.

Configurations

The application passes URLs that an untrusted party can influence to hackney and relies on its own host allowlist, built on uri_string:parse/1 or inet:parse_address/1, to keep requests away from internal addresses.

Summary

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.

Details

1. Challenge. hackney_http_connect:do_handshake_with_auth/9 in src/hackney_http_connect.erl sends the CONNECT request to the proxy. When the proxy answers 407 and the proxy_auth_fun option is set, it hands the status code and the parsed response headers to hackney_http_connect:handle_proxy_auth/11.

2. Callback result. handle_proxy_auth/11 calls the caller's proxy_auth_fun with those two values. On {ok, AuthHeader} it removes any existing Proxy-Authorization header and appends the binary <<"Proxy-Authorization: ", AuthHeader/binary>> to the header list, then retries the handshake with it.

3. Splitting. The header list is joined with CRLF into the CONNECT request. A CR, LF or NUL byte inside AuthHeader therefore ends the Proxy-Authorization line early and the rest is sent as further header lines. The target host and the request headers go through control-byte checks on this path; the callback result did not. The fix applies the same has_ctl_bytes/1 check to it and returns {error, {proxy_auth_error, invalid_header}}.

Impact

A party who controls what the application's proxy_auth_fun returns, for instance through the challenge headers of a proxy it can influence, can add header lines to the CONNECT request the client sends to its proxy.

Workarounds

Check the value your proxy_auth_fun is about to return for CR, LF and NUL bytes and return {error, Reason} instead when one is present. The callback runs in the application, so the check can be made there.

Configurations

The client connects through an HTTP CONNECT proxy with the proxy_auth_fun option set, and the callback builds its result from data an untrusted party can influence, such as the proxy's 407 challenge headers. Deployments without proxy_auth_fun, or whose callback returns a fixed credential, are not affected.

Summary

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.

Details

1. Unbounded accumulation. hackney:request/5 with a body, and hackney:body/1 after start_response/1, read the response in src/hackney_conn.erl through read_full_body/2, which appends each chunk to a binary accumulator until the body ends. The HTTP/2 and HTTP/3 synchronous paths accumulate stream data the same way. No option caps the size.

2. One-step decompression. With {auto_decompress, true} hackney sends Accept-Encoding: gzip, deflate. Once the body is complete, maybe_decompress_body/2 dispatches on Content-Encoding to decompress_gzip/1 (zlib:gunzip/1) or decompress_deflate/1 (zlib:inflate/2). Both return the whole output at once, so the inflated size is bounded only by the compression ratio. The report measured a 1 MB gzip body inflating to 1 GB on hackney 4.8.4.

Proof of concept

1. Build a gzip stream whose inflated size is 1 GB from a reused 64 KB chunk of zero bytes (deflate with window bits 31, best compression). The stream is about 1 MB on the wire.
2. Start a TCP listener on loopback that accepts one connection, reads the request, and answers HTTP/1.1 200 OK with Content-Encoding: gzip, a Content-Length matching the stream, Connection: close, and the stream as body.
3. From a node running a vulnerable hackney, call hackney:request(get, Url, [], <<>>, [{auto_decompress, true}, with_body]) against that listener.
4. Observe the returned body of 1,048,576,000 bytes and the VM memory growing by about 1.8 GB for a 1,019,197 byte response. A larger stream, or an endless body without auto_decompress, drives the node out of memory.

Impact

A server the client requests can make the client allocate memory proportional to the body it sends, or to its decompressed size, until the node runs out of memory.

Workarounds

Leave auto_decompress disabled (the default). Without it hackney_conn:maybe_decompress_body/2 never inflates the body, which closes the amplification half. The uncapped raw body read has no workaround.

Summary

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.

Details

1. Default trust options. hackney_ssl:check_hostname_opts/1 builds the verify_peer options for every TLS connection: the certifi cacerts, a hostname verify_fun, and {partial_chain, fun hackney_ssl:partial_chain/1}. The callback walks the peer chain and returns {trusted_ca, Cert} for the first certificate whose public key matches a root in the bundled certifi store, which lets OTP accept chains that end in a cross-signed root.

2. Merge keeps the callback. When the caller passes ssl_options, hackney_ssl:merge_ssl_opts/3 merges them over the defaults with the caller's values winning per key. cacerts or cacertfile replace the trust store, and a cacertfile removes the default cacerts, but partial_chain has no counterpart in the caller's options and stays.

3. Validation. OTP consults partial_chain before the configured trust store. A peer chain that carries any publicly trusted root therefore gets that root as its trust anchor, and the pinned cacerts are never consulted. Only the hostname verify_fun still constrains the attacker.

Impact

An attacker positioned between the client and a server pinned to a private CA, holding a publicly trusted certificate for the pinned hostname, can impersonate the server and read or modify the traffic the client sends and receives.

Workarounds

Pass your own {partial_chain, Fun} in ssl_options alongside cacerts or cacertfile. A caller-supplied partial_chain replaces hackney's in the merge, and a callback that returns unknown_ca makes OTP validate against the configured cacerts only.

Configurations

The caller passes cacerts or cacertfile in ssl_options to restrict trust to a private CA, without a partial_chain of its own. Connections that use hackney's default certifi trust store are not affected.