| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| 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`). |
| With the wolfSSL backend, when CA caching is enabled and an
`CURLOPT_SSL_CTX_FUNCTION` callback replaces the trust store, libcurl can
silently reinstall the cached store after the callback returns. A certificate
trusted by the cached store but rejected by the callback-selected store is
then incorrectly accepted. |
| A `Set-Cookie:` header using tab (horizontal tab, ASCII code 9) instead of
space (ascii code 32) immediately before the `Secure` attribute causes curl to
store the cookie without its Secure flag. The cookie might then wrongfully be
sent over plaintext HTTP on subsequent requests to the same host. |
| 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 `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 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 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. |
| 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. |
| A vulnerability in libcurl caused the HTTP `Referer:` header to persist even
when explicitly cleared. While the documentation states that passing NULL to
`CURLOPT_REFERER` suppresses the header, the option failed to clear the
internal state. As a result, the previous referrer string was erroneously
reused and sent in subsequent requests, potentially leaking sensitive
information to unintended servers. |
| In this scenario, libcurl first uses a proper HTTP/3 server for the initial
transfers, and when it makes a second transfer to the same site it has been
replaced by the attacker's impostor machine - without a valid certificate.
When libcurl returns to the hostname the second time with a cached SSL session
(`CURLOPT_SSL_SESSIONID_CACHE` is not disabled) and early data enabled (the
`CURLSSLOPT_EARLYDATA` bit is set in `CURLOPT_SSL_OPTIONS`), libcurl might
send off the second request's bytes on that new connection *before* enforcing
the certificate verification failure. Potentially leaking sensitive
information. |
| When asked to both use a `.netrc` file for credentials and to follow HTTP
redirects, libcurl could leak the password used for the first host to the
followed-to host under certain circumstances. |
| libcurl might in some circumstances reuse the wrong connection for SMB(S)
transfers.
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 criteria must be met. Due to a logical
error in the code, a network transfer operation that was requested by an
application could wrongfully reuse an existing SMB connection to the same
server that was using a different "share" than the new subsequent transfer
should.
This could in unlucky situations lead to the download of the wrong file or the
upload of a file to the wrong place. When this happens, the same credentials
are used and the server name is the same. |
| libcurl might in some circumstances reuse the wrong connection when asked to
do an authenticated HTTP(S) request after a Negotiate-authenticated one, when
both use the same host.
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 criteria must 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.
An application that first uses Negotiate authentication to a server with
`user1:password1` and then does another operation to the same server asking
for any authentication method but for `user2:password2` (while the previous
connection is still alive) - the second request gets confused and wrongly
reuses the same connection and sends the new request over that connection
thinking it uses a mix of user1's and user2's credentials when it is in fact
still using the connection authenticated for user1... |
| 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. |
| libcurl might in some circumstances reuse the wrong connection when asked to
do Negotiate-authenticated ones, even when they are set to use different
'services'.
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 criteria must 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 services. |
| A use-after-free vulnerability exists in libcurl when an application
configures an HTTP/2 stream-dependency tree via `CURLOPT_STREAM_DEPENDS` or
`CURLOPT_STREAM_DEPENDS_E`, subsequently invokes `curl_easy_reset()`, and
finally terminates the handle with `curl_easy_cleanup()`. During this final
cleanup phase, libcurl attempts to access and modify an internal structure
that was already freed during the reset operation. |
| Successfully using libcurl to do a transfer to a specific HTTP origin
(`hostA`) with **Digest** authentication and then changing the origin to a
different one (`hostB`) for a second transfer, reusing the same handle, makes
libcurl wrongly pass on the `Authorization:` header field meant for `hostA`,
to `hostB`. |
| libcurl keeps previously used connections in a connection pool for subsequent
transfers to reuse if one of them matches the setup.
An easy handle that first uses default native CA trust can continue trusting
the native platform store after the application switches that same handle to
custom CA material for a later transfer. |
| A flaw in curl’s cookie parsing logic allows a malicious HTTP server to set
'super cookies' that bypass the Public Suffix List check. This enables an
attacker-controlled origin to inject cookies that curl subsequently scopes and
transmits to unrelated third-party domains. |
