| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| 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... |
| 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 designed to work.
An application that allows Negotiate authentication to a server (that responds
wanting Negotiate) with `user1:password1` and then does another operation to
the same server also using Negotiate but with `user2:password2` (while the
previous connection is still alive) - the second request wrongly reused the
same connection and since it then sees that the Negotiate negotiation is
already made, it sends the request over that connection thinking it uses
the user2 credentials when it is in fact still using the connection
authenticated for user1...
The set of authentication methods to use is set with `CURLOPT_HTTPAUTH`.
Applications can disable libcurl's reuse of connections and thus mitigate this
problem, by using one of the following libcurl options to alter how
connections are or are not reused: `CURLOPT_FRESH_CONNECT`,
`CURLOPT_MAXCONNECTS` and `CURLMOPT_MAX_HOST_CONNECTIONS` (if using the
curl_multi API). |
| 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. |
| 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`. |
| When doing TLS related transfers with reused easy or multi handles and
altering the `CURLSSLOPT_NO_PARTIALCHAIN` option, libcurl could accidentally
reuse a CA store cached in memory for which the partial chain option was
reversed. Contrary to the user's wishes and expectations. This could make
libcurl find and accept a trust chain that it otherwise would not. |
| When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer
performs a cross-protocol redirect to a second URL that uses an IMAP, LDAP,
POP3 or SMTP scheme, curl might wrongly pass on the bearer token to the new
target host. |
| When doing multi-threaded LDAPS transfers (LDAP over TLS) with libcurl,
changing TLS options in one thread would inadvertently change them globally
and therefore possibly also affect other concurrently setup transfers.
Disabling certificate verification for a specific transfer could
unintentionally disable the feature for other threads as well. |
| When using `CURLOPT_PINNEDPUBLICKEY` option with libcurl or `--pinnedpubkey`
with the curl tool, curl should check the public key of the server certificate
to verify the peer.
This check was skipped in a certain condition that would then make curl allow
the connection without performing the proper check, thus not noticing a
possible impostor. To skip this check, the connection had to be done with QUIC
with ngtcp2 built to use GnuTLS and the user had to explicitly disable the
standard certificate verification. |
| curl's WebSocket code did not update the 32-bit mask pattern for each new
outgoing frame as the specification says. Instead it used a fixed mask that
persisted and was used throughout the entire connection.
A predictable mask pattern allows for a malicious server to induce traffic
between the two communicating parties that could be interpreted by an involved
proxy (configured or transparent) as genuine, real, HTTP traffic with content
and thereby poison its cache. That cached poisoned content could then be
served to all users of that proxy. |
| 1. A cookie is set using the `secure` keyword for `https://target`
2. curl is redirected to or otherwise made to speak with `http://target` (same
hostname, but using clear text HTTP) using the same cookie set
3. The same cookie name is set - but with only a slash as path (`path="/"`).
Since this site is not secure, the cookie *should* be ignored.
4. A bug in the path comparison logic makes curl read outside a heap buffer
boundary
The bug either causes a crash or it potentially makes the comparison come to
the wrong conclusion and lets the clear-text site override the contents of the
secure cookie, contrary to expectations and depending on the memory contents
immediately following the single-byte allocation that holds the path.
The presumed and correct behavior would be to plainly ignore the second set of
the cookie since it was already set as secure on a secure host so overriding
it on an insecure host should not be okay. |
| 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 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. |
| 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. |
| The curl logic that works with SASL authentication could end up cleaning up
the GSASL context *twice* without clearing the pointer in between, making it
`free()` the same pointer twice. |
| An issue in curl’s QUIC UDP receive function allows a malicious HTTP/3 server
to trigger a remote denial of service against a curl or libcurl client.
Because the helper function discards zero-length UDP datagrams before counting
them toward the per-call packet budget, a connected QUIC peer can continuously
stream empty datagrams to indefinitely stall the client. |
| By default, curl automatically responds to WebSocket PING frames. Because curl
lacks an upper bound on memory allocation for unacknowledged frames, a
malicious server can exhaust all available memory by flooding curl with rapid,
sequential PING messages. |
| 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`. |
| 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. |
| A vulnerability exists where a new transfer that uses STARTTLS to upgrade the
connection might reuse an existing live connection even though the TLS
configuration mismatches so it should not. |
