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.
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.
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 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.
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.
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.
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.
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.
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.
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`.