Martin Karrer

Improper validation of certificates with host mismatches allows an adversary in the middle to impersonate a TLS peer using a certificate with a partial-label wildcard. The `try match wildcard/4` function in `src/ssl verify hostname.erl` only anchors text before and after the asterisk in identifiers like `f*.example.net`, allowing the wildcard to consume dots and accept certificates for unauthorized domains such as `f.evil.example.net`. This contradicts RFC 6125, which restricts wildcards to the left-most label. Additionally, the matcher allows `*.168.1.1` to match the IP literal `192.168.1.1`. This issue affects clients that disable Server Name Indication (SNI), servers verifying client certificate hostnames, and direct callers of the `verify cert hostname/2` function.

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

Improper certificate validation in `hackney ssl` allows an on-path attacker to impersonate a server pinned to a private certificate authority. This occurs because `hackney ssl:merge ssl opts/3` retains a default callback `{partial chain, fun hackney ssl:partial chain/1}` even when a user replaces the trust store with `cacerts` or `cacertfile` in `ssl options`. Since OTP prioritizes this callback over the configured trust store, any certificate chain ending in a publicly trusted root is accepted, bypassing the private CA pinning. The attacker must possess a publicly trusted certificate for the pinned hostname to succeed.

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