Ce mail provient de l'extérieur, restons vigilants ===================================================================== CERT-Renater Note d'Information No. 2026/VULN004 _____________________________________________________________________ DATE : 07/01/2026 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running curl versions prior to 8.18.0. ===================================================================== https://curl.se/docs/CVE-2025-13034.html https://curl.se/docs/CVE-2025-14017.html https://curl.se/docs/CVE-2025-14524.html https://curl.se/docs/CVE-2025-14819.html https://curl.se/docs/CVE-2025-15079.html https://curl.se/docs/CVE-2025-15224.html _____________________________________________________________________ CVE-2025-13034 No QUIC certificate pinning with GnuTLS Project curl Security Advisory, January 7 2026 - Permalink VULNERABILITY When using CURLOPT_PINNEDPUBLICKEY 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. Reported-by: Stanislav Fort (Aisle Research) Patched-by: Daniel Stenberg Thanks a lot! _____________________________________________________________________ CVE-2025-14017 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! _____________________________________________________________________ CVE-2025-14524 bearer token leak on cross-protocol redirect Project curl Security Advisory, January 7 2026 - Permalink VULNERABILITY When an oauth2 bearer token is used for an HTTP(S) transfer, and that transfer performs a cross-protocol redirect to a second URL that uses an IMAP, LDAP, POP3 or SMTP scheme, curl might wrongly pass on th bearer token to the new target host. INFO By default, curl only allows redirects to HTTP(S) and FTP(S), but can be asked to allow redirects to all protocols curl supports. This vulnerability only triggers for users who use OAUTH2 bearer and who actively enable redirects to one of the four protocols mentioned above and one of those schemes is used in the HTTP redirect. A highly unusual combination. The redirect-to URL needs to have the user name component set (but not the password) to trigger this flaw. This token leak also happens if the redirect is done to the same hostname, just a different protocol (and port). The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2025-14524 to this issue. CWE-522: Insufficiently Protected Credentials Severity: Low AFFECTED VERSIONS Affected versions: curl 7.33.0 to and including 8.17.0 Not affected versions: curl < 7.33.0 and >= 8.18.0 Introduced-in: https://github.com/curl/curl/commit/06c1bea72faabb6fad4b7ef8 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/1a822275d333dc6da6043497160fd RECOMMENDATIONS A - Upgrade curl to version 8.18.0 B - Avoid allowing cross-protocol redirects C - Avoid using oauth2 bearer tokens TIMELINE This issue was reported to the curl project on December 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: anonymous237 on hackerone Patched-by: Daniel Stenberg Thanks a lot! _____________________________________________________________________ CVE-2025-14819 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 CURLSSLOPT_NO_PARTIALCHAIN 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 CURLOPT_SSL_OPTIONS has a bit called CURLSSLOPT_NO_PARTIALCHAIN which if set makes libcurl not set the OpenSSL store flag called X509_V_FLAG_PARTIAL_CHAIN. 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 CURLOPT_CA_CACHE_TIMEOUT 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 CURLSSLOPT_NO_PARTIALCHAIN C - Switch off CA caching with CURLOPT_CA_CACHE_TIMEOUT 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! _____________________________________________________________________ CVE-2025-15079 libssh global knownhost override Project curl Security Advisory, January 7 2026 - Permalink VULNERABILITY When doing SSH-based transfers using either SCP or SFTP, and setting the knownhosts file, libcurl could still mistakenly accept connecting to hosts not present in the specified file if they were added as recognized in the libssh global knownhosts file. INFO This flaw only exists when libcurl is built to use the libssh backend, not the libssh2 based one. This problem happened because libssh has a somewhat surprising API choice where they fall back to a built-in global knownhosts file if the host was not found in the specified one. The global file that was used as a fallback gets its set path at build time. The fix now makes libcurl set both knownhost files to the same path. The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2025-15079 to this issue. CWE-297: Improper Validation of Certificate with Host Mismatch Severity: Low AFFECTED VERSIONS Affected versions: curl 7.58.0 to and including 8.17.0 Not affected versions: curl < 7.58.0 and >= 8.18.0 Introduced-in: https://github.com/curl/curl/commit/c92d2e14cfb0db662f958effd2ac86f99 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/adca486c125d9a6d9565b9607a19dce803 RECOMMENDATIONS A - Upgrade curl to version 8.18.0 B - Build curl with the libssh2 backend C - Avoid using SFTP or SCP TIMELINE This issue was reported to the curl project on December 24, 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: Harry Sintonen Patched-by: Daniel Stenberg Thanks a lot! _____________________________________________________________________ CVE-2025-15224 libssh key passphrase bypass without agent set Project curl Security Advisory, January 7 2026 - Permalink VULNERABILITY 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. INFO This flaw only exists when libcurl is built to use the libssh backend, not the libssh2 based one. This problem happened because libssh has a somewhat surprising API choice where they fall back to agent authentication. It should be noted that the authentication still only succeeds if the local SSH agent actually has the correct passphrase. The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2025-15224 to this issue. CWE-287: Improper Authentication Severity: Low AFFECTED VERSIONS Affected versions: curl 7.58.0 to and including 8.17.0 Not affected versions: curl < 7.58.0 and >= 8.18.0 Introduced-in: https://github.com/curl/curl/commit/c92d2e14cfb0db662f958effd2ac86f99 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/16d5f2a5660c61cc27bd5f1c7f512391d1c92 RECOMMENDATIONS A - Upgrade curl to version 8.18.0 B - Build curl with the libssh2 backend C - Avoid using SFTP or SCP TIMELINE This issue was reported to the curl project on December 28, 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: Harry Sintonen Patched-by: Harry Sintonen Thanks a lot! ========================================================= + CERT-RENATER | tel : 01-53-94-20-44 + + 23/25 Rue Daviel | fax : 01-53-94-20-41 + + 75013 Paris | email:cert@support.renater.fr + =========================================================