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.
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.
When a user invokes curl using a schemeless URL combined with
`--proto-default` sftp (or scp), a disconnect occurs between the tool layer
and libcurl. The tool layer incorrectly infers the URL scheme, which
erroneously bypasses the initialization of critical SSH security options like
CURLOPT_SSH_HOST_PUBLIC_KEY_SHA256 and CURLOPT_SSH_KNOWNHOSTS. Conversely, the
libcurl runtime successfully honors CURLOPT_DEFAULT_PROTOCOL and establishes
the connection via SFTP/SCP as specified. Because the tool layer skipped the
security configuration, these SSH host verification options are silently
omitted, causing curl to connect to an unverified SSH remote host without
throwing an error.