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.
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.
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.
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.
802.1X. An authentication issue was addressed with improved state management.
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
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.
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?
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
cURL libcurl is vulnerable to a stack-based buffer overflow, caused by improper bounds checking by the toolcbwrt component. By sending a specially crafted request, a remote attacker could overflow a buffer and execute arbitrary code or cause a denial of service condition on the system.
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
On Thu, Oct 05, 2023 at 10:14:49AM +0200, Erik Auerswald wrote: Hi,
there is a pre-announcement of a curl security problem with high severity that can be found on GitHub:
- https://github.com/curl/curl/discussions - https://github.com/curl/curl/discussions/12026 I wonder if this could also be coordinated through CERT VINCE since there will be a wider impact than those on the distros mailing list.
Thanks,
-- Shawn Webb Cofounder / Security Engineer HardenedBSD
https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/ShawnWebb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc
Hi,
there is a pre-announcement of a curl security problem with high severity that can be found on GitHub:
- https://github.com/curl/curl/discussions - https://github.com/curl/curl/discussions/12026
(I have seen a link to it from some web site, and did not see it on this list yet.)
There is little information available, the GitHub discussions post says:
"We are cutting the release cycle short and will release curl 8.4.0 on October 11, including fixes for a severity HIGH CVE and one severity LOW. The one rated HIGH is probably the worst curl security flaw in a long time.
The new version and details about the two CVEs will be published around 06:00 UTC on the release day.
CVE-2023-38545: severity HIGH (affects both libcurl and the curl tool) CVE-2023-38546: severity LOW (affects libcurl only, not the tool)
Now you know. Plan accordingly."
Best regards, Erik
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.
Curl before 7.49.1 in Apple OS X before macOS Sierra prior to 10.12 allows remote or local attackers to execute arbitrary code, gain sensitive information, cause denial-of-service conditions, bypass security restrictions, and perform unauthorized actions. This may aid in other attacks.
curl before 7.53.0 has an incorrect TLS Certificate Status Request extension feature that asks for a fresh proof of the server's certificate's validity in the code that checks for a test success or failure. It ends up always thinking there's valid proof, even when there is none or if the server doesn't support the TLS extension in question. This could lead to users not detecting when a server's certificate goes invalid or otherwise be mislead that the server is in a better shape than it is in reality. This flaw also exists in the command line tool (--cert-status).
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, allows remote attackers to obtain sensitive information, cause a denial of service (crash), or possibly have unspecified other impact via a wildcard certificate name, which triggers an out-of-bounds read.
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."
curl and libcurl before 7.57.0 on 32-bit platforms allow attackers to cause a denial of service (out-of-bounds access and application crash) or possibly have unspecified other impact because too little memory is allocated for interfacing to an SSL library.
curl, as shipped in Red Hat Enterprise Linux 6 before version 7.19.7-53, did not correctly backport the fix for CVE-2015-3148 because it did not reflect the fact that the HAVEGSSAPI define was meanwhile substituted by USEHTTPNEGOTIATE. This issue was introduced in RHEL 6.7 and affects RHEL 6 curl only.