When `CURLOPT_PINNEDPUBLICKEY` is configured alongside options that disable
standard peer verification (`CURLOPT_SSL_VERIFYPEER = 0` and
`CURLOPT_SSL_VERIFYHOST = 0`), libcurl fails to enforce public key pinning on
connections established without a presented server certificate. Bypassing the
pinning check under these disabled-verification conditions allows
unauthenticated connections to succeed when they should be rejected.
A flaw in libcurl makes it wrongly reuse an existing HTTPS connection setup
for a given hostname even when using a different Native CA Store setting
(`CURLSSLOPT_NATIVE_CA`) than when the connection was created.
When libpsl support is enabled, libcurl fails to enforce the Public Suffix
List boundary check when processing a `Set-Cookie` header where the `Domain`
attribute explicitly matches an origin host that is itself a public suffix
(e.g., `Domain=co.uk` set by `co.uk`).
Instead of coercing it into a strict host-only cookie, libcurl saves the
cookie with wildcard domain scope (`.co.uk`). Consequently, the cookie is
inappropriately included in subsequent outbound requests or HTTP redirects to
arbitrary sibling subdomains under the same public suffix (e.g.,
`attacker.co.uk`).
A flaw in libcurl's handling of HTTP/2 Server Push streams, when the parent
handle is set to share connections with other handles, can lead to
use-after-free in the cleanup process.
A flaw in libcurl makes it wrongly reuse an HTTP connection setup for a given
hostname using Negotiate authentication, when the initial request is done
using empty credentials. This can make user B's request get sent over user A's
previously authenticated connection.
A flaw in the libcurl SASL negotiation for LDAP authentication allows an
incomplete handshake sequence to be misinterpreted as a successful
cryptographic verification. An attacker executing a Man-in-the-Middle (MITM)
attack can inject a premature or shortcut response that bypasses complete peer
validation.
When reusing a libcurl handle for sequential transfers driven by
environment-variable proxy configuration, libcurl fails to clear the proxy
authentication state between requests. Specifically, if the initial transfer
authenticates against `proxyA` using Digest auth, a subsequent transfer routed
through `proxyB` erroneously leaks the `Proxy-Authorization:` header intended
solely for `proxyA`.
libcurl would reuse a previously created connection even when some mTLS config
related option had been changed that should have prohibited reuse.
libcurl keeps previously used connections in a connection pool for subsequent
transfers to reuse if one of them matches the setup. However, some TLS
settings related to client certificates were left out from the configuration
match checks, making them match too easily. In particular options related to
the private key.
libcurl had a flaw that when instructed to clear proxy authentication
credentials which made it not do so, leaving the old credentials around to get
used for subsequent transfers that should not know nor use them.
When a libcurl-based application performs transfers via `SCP://` or `SFTP://`
and utilizes the `CURLOPT_SSH_KEYFUNCTION` callback, it may silently accept an
untrusted server. This vulnerability occurs when a server presents a host key
type that does not match the specific key type already recorded for that host
in the `known_hosts` file. Instead of rejecting the mismatch, the callback
mechanism fails to properly enforce the restriction, allowing the connection
to succeed without warning and risking a potential man-in-the-middle attack.