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.
Last updated 2 July 2026
Last updated 2 July 2026
Last updated 10 July 2026
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.
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.
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 (CURLOPTSSLSESSIONIDCACHE is not disabled) and early data enabled (the CURLSSLOPTEARLYDATA bit is set in CURLOPTSSLOPTIONS), libcurl might send off the second request's bytes on that new connection before enforcing the certificate verification failure. Potentially leaking sensitive information.
incomplete mTLS config matching in conn reuse
Last updated 2 July 2026
env-set cross-proxy Digest auth state leak
Accessibility. This issue was addressed through improved state management.
bad reuse of HTTP Negotiate connection
Accessibility. This issue was addressed through improved state management.
Accelerate. An out-of-bounds read was addressed with improved bounds checking.
A use-after-free vulnerability exists in libcurl when an application configures an HTTP/2 stream-dependency tree via CURLOPTSTREAMDEPENDS or CURLOPTSTREAMDEPENDSE, subsequently invokes curleasyreset(), and finally terminates the handle with curleasycleanup(). During this final cleanup phase, libcurl attempts to access and modify an internal structure that was already freed during the reset operation.
Accelerate. An out-of-bounds read was addressed with improved bounds checking.
802.1X. An authentication issue was addressed with improved state management.
Accessibility. A logging issue was addressed with improved data redaction.
Last updated 2 July 2026
cross-origin Digest auth state leak
eventfd double close
netrc and default credential leak
gzip integer overflow
libcurl supports pinning of the server certificate public key for HTTPS transfers. Due to an omission, this check is not performed when connecting with QUIC for HTTP/3, when the TLS backend is wolfSSL. Documentation says the option works with wolfSSL, failing to specify that it does not for QUIC and HTTP/3. Since pinning makes the transfer succeed if the pin is fine, users could unwittingly connect to an impostor server without noticing.
libcurl accidentally skips the certificate verification for QUIC connections when connecting to a host specified as an IP address in the URL. Therefore, it does not detect impostors or man-in-the-middle attacks.
Accounts. The issue was addressed with improved checks.
Accounts. The issue was addressed with improved checks.
Accounts. The issue was addressed with improved checks.
Accounts. The issue was addressed with improved checks.
curl versions 7.54.1 through 7.60.0 are vulnerable to a heap-based buffer overflow in the Curlsmtpescapeeob() function when uploading data over SMTP and using a reduced read buffer. An attacker could exploit this by convincing a user to use curl to upload data over SMTP with a reduced buffer to cause a crash or corrupt memory.