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.
When performing transfers via libcurl’s multi interface, pooled TLS
connections can outlive their originating easy handles. In OpenSSL 3 provider
configurations, libcurl attaches an allocated library context to the easy
handle's state and passes it to OpenSSL without acquiring an ownership
reference; destroying the easy handle prematurely frees this context while the
active connection retains a dangling pointer, leading to a heap-use-after-free
upon subsequent I/O or post-handshake operations.
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 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.
Calling `curl_easy_pause()` within the event-based `CURLMOPT_SOCKETFUNCTION`
callback triggers a use-after-free vulnerability, where libcurl attempts to
store a flag using a dangling struct pointer immediately after that pointer's
memory has been freed.
curl would wrongly reuse an existing HTTP proxy connection doing CONNECT to a
server, even if the new request uses different credentials for the HTTP proxy.
The proper behavior is to create or use a separate connection.
When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer
performs a redirect to a second URL, curl could leak that token to the second
hostname under some circumstances.
If the hostname that the first request is redirected to has information in the
used .netrc file, with either of the `machine` or `default` keywords, curl
would pass on the bearer token set for the first host also to the second one.
libcurl can in some circumstances reuse the wrong connection when asked to do
an Negotiate-authenticated HTTP or HTTPS request.
libcurl features a pool of recent connections so that subsequent requests can
reuse an existing connection to avoid overhead.
When reusing a connection a range of criterion must first be met. Due to a
logical error in the code, a request that was issued by an application could
wrongfully reuse an existing connection to the same server that was
authenticated using different credentials. One underlying reason being that
Negotiate sometimes authenticates *connections* and not *requests*, contrary
to how HTTP is design