When doing SSH-based transfers using either SCP or SFTP, and asked to do public key authentication, curl would wrongly still ask and authenticate using a locally running SSH agent.
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.
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.
802.1X. An authentication issue was addressed with improved state management.
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 CURLOPTSSHHOSTPUBLICKEYSHA256 and CURLOPTSSHKNOWNHOSTS. Conversely, the libcurl runtime successfully honors CURLOPTDEFAULTPROTOCOL 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.
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 just a slash as path (path='/'). Since this site is not secure, the cookie should just 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.
OpenSSL partial chain store policy bypass =========================================
Project curl Security Advisory, January 7 2026 - Permalink
VULNERABILITY -------------
When doing TLS related transfers with re-used easy or multi handles and altering the CURLSSLOPTNOPARTIALCHAIN 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.
INFO ----
As a performance enhancement, in libcurl's OpenSSL related backend code, it holds the loaded CA store cached in memory. This cache is held in memory up to 24 hours by default until refreshed.
The libcurl option CURLOPTSSLOPTIONS has a bit called CURLSSLOPTNOPARTIALCHAIN which if set makes libcurl not set the OpenSSL store flag called X509VFLAGPARTIALCHAIN.
curl contains support for several different TLS backends. This flaw only exists when libcurl uses OpenSSL (or one of the many OpenSSL forks) in runtime.
This only affects TLS related transfers and only if CURLOPTCACACHETIMEOUT is not disabled (set to zero).
libcul still verifies the certificate and returns error if it cannot, even with this flaw. It just might accept a partial trust chain that it otherwise would not.
Applications rarely toggle this option individually for different transfers.
The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2025-14819 to this issue.
CWE-295: Improper Certificate Validation
Severity: Low
AFFECTED VERSIONS -----------------
- Affected versions: curl 7.87.0 to and including 8.17.0 - Not affected versions: curl < 7.87.0 and >= 8.18.0 - Introduced-in: https://github.com/curl/curl/commit/3c16697ebd796f799227b
libcurl is used by many applications, but not always advertised as such!
This bug is not considered a C mistake. It is not likely to have been avoided had we not been using C.
This flaw does not affect the curl command line tool.
SOLUTION ------------
Starting in curl 8.18.0, this mistake is fixed.
- Fixed-in: https://github.com/curl/curl/commit/cd046f6c93b39d673a58c1864
RECOMMENDATIONS --------------
A - Upgrade curl to version 8.18.0
B - Avoid using CURLSSLOPTNOPARTIALCHAIN
C - Switch off CA caching with CURLOPTCACACHETIMEOUT
TIMELINE --------
This issue was reported to the curl project on December 16, 2025. We contacted distros@openwall on December 30, 2025.
curl 8.18.0 was released on January 7 2026 around 07:00 UTC, coordinated with the publication of this advisory.
The curl security team is not aware of any active exploits using this vulnerability.
CREDITS -------
- Reported-by: Stanislav Fort (Aisle Research) - Patched-by: Daniel Stenberg
Thanks a lot!
--
/ daniel.haxx.se || https://rock-solid.curl.dev
broken TLS options for threaded LDAPS =====================================
Project curl Security Advisory, January 7 2026 - Permalink
VULNERABILITY -------------
When doing multithreaded 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.
INFO ----
curl contains support for several different LDAP backends. This flaw only exists when libcurl was built to use the "legacy" non-Windows LDAP support (the lib/ldap.c source code). Notably, builds using OpenLDAP are not affected.
It does not apply to users of WinLDAP (the flavor of LDAP provided in Windows) since that API does not offer those TLS related options.
This is only a potential problem when doing LDAP transfers concurrently in more than one thread. The global state was used for the connection setup (only), so this vulnerability is highly timing sensitive.
The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2025-14017 to this issue.
CWE-567: Unsynchronized Access to Shared Data in a Multithreaded Context
Severity: Medium
AFFECTED VERSIONS -----------------
- Affected versions: curl 7.17.0 to and including 8.17.0 - Not affected versions: curl < 7.17.0 and >= 8.18.0 - Introduced-in: https://github.com/curl/curl/commit/ccba0d10b6baf5c73ca
libcurl is used by many applications, but not always advertised as such!
This bug is not considered a C mistake. It is not likely to have been avoided had we not been using C.
This flaw does not affect the curl command line tool.
SOLUTION ------------
Starting in curl 8.18.0, this mistake is fixed.
- Fixed-in: https://github.com/curl/curl/commit/39d1976b7f709a516e324333
RECOMMENDATIONS --------------
A - Upgrade curl to version 8.18.0
B - Build curl with OpenLDAP
C - Avoid using LDAP
TIMELINE --------
This issue was reported to the curl project on December 1, 2025.
curl 8.18.0 was released on January 7 2026 around 07:00 UTC, coordinated with the publication of this advisory.
The curl security team is not aware of any active exploits using this vulnerability.
CREDITS -------
- Reported-by: Stanislav Fort (Aisle Research) - Patched-by: Daniel Stenberg
Thanks a lot!
--
/ daniel.haxx.se || https://rock-solid.curl.dev
No QUIC certificate pinning with GnuTLS =======================================
Project curl Security Advisory, January 7 2026 - Permalink
VULNERABILITY -------------
When using CURLOPTPINNEDPUBLICKEY 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 verifiation.
INFO ----
curl contains support for several different QUIC and TLS backends. Other QUIC backends or the ngtcp2 backend built with another TLS library are not affected by this flaw.
If instead connecting to a server over HTTP/1 or HTTP/2, the pinning check works fine and does properly detect impostors.
This issue is similar to CVE-2025-5025 but for a different TLS library.
The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2025-13034 to this issue.
CWE-295: Improper Certificate Validation
Severity: Medium
AFFECTED VERSIONS -----------------
- Affected versions: curl 8.8.0 to and including 8.17.0 - Not affected versions: curl < 8.8.0 and >= 8.18.0 - Introduced-in: https://github.com/curl/curl/commit/3210101088dfa3d6a125
libcurl is used by many applications, but not always advertised as such!
This bug is not considered a C mistake. It is not likely to have been avoided had we not been using C.
This flaw also affects the curl command line tool.
SOLUTION ------------
Starting in curl 8.18.0, this mistake is fixed.
- Fixed-in: https://github.com/curl/curl/commit/3d91ca8cdb3b434226e743946
RECOMMENDATIONS --------------
A - Upgrade curl to version 8.18.0
B - Build curl with another TLS library
C - Avoid using HTTP/3
TIMELINE --------
This issue was reported to the curl project on November 9, 2025. We contacted distros@openwall on December 30, 2025.
curl 8.18.0 was released on January 7 2026 around 07:00 UTC, coordinated with the publication of this advisory.
The curl security team is not aware of any active exploits using this vulnerability.
CREDITS -------
- Reported-by: Stanislav Fort (Aisle Research) - Patched-by: Daniel Stenberg
Thanks a lot!
--
/ daniel.haxx.se || https://rock-solid.curl.dev
Hi everyone,
Just wanted to pick your brain on how your security team is dealing with these types of vulnerabilities. E.g. CVE-2025-0167 (netrc and default credential leak) CVE-2024-7264 (ASN.1 date parser overread). The vulnerable curl binary is bundled with either Microsoft SQL Management Studio or resides in System32.
I've read online that you shouldn't be messing with System32 binaries unless it comes in the form of official Microsoft updates. So my question is for people handling vulnerability management within their org, how do you usually deal with these types of vulnerabilities?
The endpoints I'm dealing with are not exposed to the internet, so exploitation isn't likely. Would you set an exception for these vulnerabilities?
php-mod/curl (a wrapper of the PHP cURL extension) before 2.3.2 allows XSS via the postfilepathupload.php key parameter and the POST data to postmultidimensional.php.
On Wed, 5 Feb 2025, Fay Stegerman wrote: libcurl featured code that at run-time takes a different code path for zlib versions before 1.0.2.4 because of lack of functionality in those old versions, and this rarely used piece of code contained the vulnerable code path.
Correct, this has been fixed already in the document version we host.
--
/ daniel.haxx.se
lib/curl.rb in the Curl Gem for Ruby allows remote attackers to execute arbitrary commands via shell metacharacters in a URL.
On October 11, 2023, cURL released Version 8.4.0 of the cURL utility and the libcurl library. This release addressed two security vulnerabilities: CVE-2023-38545 - High Security Impact Rating (SIR)CVE-2023-38546 - Low SIRThis
The verifycertificate function in lib/vtls/schannel.c in libcurl 7.30.0 through 7.51.0, when built for Windows CE using the schannel TLS backend, makes it easier for remote attackers to conduct man-in-the-middle attacks via a crafted wildcard SAN in a server certificate, as demonstrated by ".com."
Absolute path traversal vulnerability in curl 7.20.0 through 7.21.1, when the --remote-header-name or -J option is used, allows remote servers to create or overwrite arbitrary files by using \ (backslash) as a separator of path components within the Content-disposition HTTP header.
cURL and libcurl 7.18.0 through 7.32.0, when built with OpenSSL, disables the certificate CN and SAN name field verification (CURLOPTSSLVERIFYHOST) when the digital signature verification (CURLOPTSSLVERIFYPEER) is disabled, which allows man-in-the-middle attackers to spoof SSL servers via an arbitrary valid certificate.
Heap-based buffer overflow in the curleasyunescape function in lib/escape.c in cURL and libcurl 7.7 through 7.30.0 allows remote attackers to cause a denial of service (application crash) or possibly execute arbitrary code via a crafted string ending in a "%" (percent) character.
A security flaw was found in the way the library of cURL, an utility for retrieval of files from remote servers, performed match of cookie domain names when making a decision if (previously stored cookies) should be sent to particular domain. Due to a bug in match function implementation, (formerly) the decision / match succeeded also in cases, where just suffix / certain part of the domain name matched the domain name, the current request originated from. A remote attacker could use this flaw to possibly hijack the user session of the victim by submitting a request containing a specially-crafted domain name.
References: [1] http://thread.gmane.org/gmane.comp.web.curl.library/38986
Acknowledgements:
Red Hat would like to thank the cURL project for reporting this issue. Upstream acknowledges YAMADA Yasuharu as the original reporter.
Stack-based buffer overflow in the Curlsaslcreatedigestmd5message function in lib/curlsasl.c in curl and libcurl 7.26.0 through 7.28.1, when negotiating SASL DIGEST-MD5 authentication, allows remote attackers to cause a denial of service (crash) and possibly execute arbitrary code via a long string in the realm parameter in a (1) POP3, (2) SMTP or (3) IMAP message.
cURL and libcurl before 7.38.0 does not properly handle IP addresses in cookie domain names, which allows remote attackers to set cookies for or send arbitrary cookies to certain sites, as demonstrated by a site at 192.168.0.1 setting cookies for a site at 127.168.0.1.
cURL and libcurl before 7.38.0 allow remote attackers to bypass the Same Origin Policy and set cookies for arbitrary sites by setting a cookie for a top-level domain.
cURL and libcurl 7.40.0 through 7.42.1 send the HTTP Basic authentication credentials for a previous connection when reusing a reset (curleasyreset) connection handle to send a request to the same host name, which allows remote attackers to obtain sensitive information via unspecified vectors.
The smbrequeststate function in cURL and libcurl 7.40.0 through 7.42.1 allows remote SMB servers to obtain sensitive information from memory or cause a denial of service (out-of-bounds read and crash) via crafted length and offset values.
The default configuration for cURL and libcurl before 7.42.1 sends custom HTTP headers to both the proxy and destination server, which might allow remote proxy servers to obtain sensitive information by reading the header contents.
cURL and libcurl 7.10.6 through 7.41.0 does not properly re-use NTLM connections, which allows remote attackers to connect as other users via an unauthenticated request, a similar issue to CVE-2014-0015.
The fixhostname function in cURL and libcurl 7.37.0 through 7.41.0 does not properly calculate an index, which allows remote attackers to cause a denial of service (out-of-bounds read or write and crash) or possibly have other unspecified impact via a zero-length host name, as demonstrated by "http://:80" and ":80."
cURL and libcurl 7.10.6 through 7.41.0 do not properly re-use authenticated Negotiate connections, which allows remote attackers to connect as other users via a request.