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.
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.
802.1X. An authentication issue was addressed with improved state management.
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.
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.
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
A use after free vulnerability exists in curl <v8.1.0 in the way libcurl offers a feature to verify an SSH server's public key using a SHA 256 hash. When this check fails, libcurl would free the memory for the fingerprint before it returns an error message containing the (now freed) hash. This flaw risks inserting sensitive heap-based data into the error message that might be shown to users or otherwise get leaked and revealed.
A denial of service vulnerability exists in curl <v8.1.0 in the way libcurl provides several different backends for resolving host names, selected at build time. If it is built to use the synchronous resolver, it allows name resolves to time-out slow operations using alarm() and siglongjmp(). When doing this, libcurl used a global buffer that was not mutex protected and a multi-threaded application might therefore crash or otherwise misbehave.
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?
A malicious server can serve excessive amounts of Set-Cookie: headers in a HTTP response to curl and curl < 7.84.0 stores all of them. A sufficiently large amount of (big) cookies make subsequent HTTP requests to this, or other servers to which the cookies match, create requests that become larger than the threshold that curl uses internally to avoid sending crazy large requests (1048576 bytes) and instead returns an error.This denial state might remain for as long as the same cookies are kept, match and haven't expired. Due to cookie matching rules, a server on foo.example.com can set cookies that also would match for bar.example.com, making it it possible for a "sister server" to effectively cause a denial of service for a sibling site on the same second level domain using this method.
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.
A use after free vulnerability exists in curl <7.87.0. Curl can be asked to tunnel virtually all protocols it supports through an HTTP proxy. HTTP proxies can (and often do) deny such tunnel operations. When getting denied to tunnel the specific protocols SMB or TELNET, curl would use a heap-allocated struct after it had been freed, in its transfer shutdown code path.
An allocation of resources without limits or throttling vulnerability exists in curl <v7.88.0 based on the "chained" HTTP compression algorithms, meaning that a server response can be compressed multiple times and potentially with differentalgorithms. The number of acceptable "links" in this "decompression chain" wascapped, but the cap was implemented on a per-header basis allowing a maliciousserver to insert a virtually unlimited number of compression steps simply byusing many headers. The use of such a decompression chain could result in a "malloc bomb", making curl end up spending enormous amounts of allocated heap memory, or trying to and returning out of memory errors.
A cleartext transmission of sensitive information vulnerability exists in curl <v7.88.0 that could cause HSTS functionality fail when multiple URLs are requested serially. Using its HSTS support, curl can be instructed to use HTTPS instead of usingan insecure clear-text HTTP step even when HTTP is provided in the URL. ThisHSTS mechanism would however surprisingly be ignored by subsequent transferswhen done on the same command line because the state would not be properlycarried on.
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
A insufficiently protected credentials vulnerability in fixed in curl 7.83.0 might leak authentication or cookie header data on HTTP redirects to the same host but another port number.
curl can be told to parse a .netrc file for credentials. If that file endsin a line with 4095 consecutive non-white space letters and no newline, curlwould first read past the end of the stack-based buffer, and if the readworks, write a zero byte beyond its boundary.This will in most cases cause a segfault or similar, but circumstances might also cause different outcomes.If a malicious user can provide a custom netrc file to an application or otherwise affect its contents, this flaw could be used as denial-of-service.
A flaw was found in curl in the way curl handles credentials when downloading content using the Metalink feature. This flaw allows malicious actors controlling a hosting server to gain access to credentials provided while downloading content without the user's knowledge. The highest threat from this vulnerability is to confidentiality.
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.