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