Ce mail provient de l'extérieur, restons vigilants ===================================================================== CERT-Renater Note d'Information No. 2026/VULN678 _____________________________________________________________________ DATE : 25/06/2026 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running curl, libcurl versions prior to 8.21.0. ===================================================================== https://curl.se/docs/CVE-2026-8286.html https://curl.se/docs/CVE-2026-8458.html https://curl.se/docs/CVE-2026-8924.html https://curl.se/docs/CVE-2026-8925.html https://curl.se/docs/CVE-2026-8926.html https://curl.se/docs/CVE-2026-8927.html https://curl.se/docs/CVE-2026-8932.html https://curl.se/docs/CVE-2026-9079.html https://curl.se/docs/CVE-2026-9080.html https://curl.se/docs/CVE-2026-9545.html https://curl.se/docs/CVE-2026-9546.html https://curl.se/docs/CVE-2026-11856.html _____________________________________________________________________ CVE-2026-8286 wrong STARTTLS connection reuse Project curl Security Advisory, June 24 2026 VULNERABILITY A vulnerability exists where a new transfer that uses STARTTLS to upgrade the connection might reuse an existing live connection even though the TLS configuration mismatches so it should not. INFO For data transfers using URL schemes that start as cleartext but upgrade to TLS, the validation logic ensuring configuration consistency between transfers is not invoked. This affects IMAP://, POP3://, SMTP://, FTP://, and LDAP:// schemes, potentially allowing connection reuse with mismatched TLS settings. The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2026-8286 to this issue. CWE-295: Improper Certificate Validation Severity: Low AFFECTED VERSIONS Affected versions: curl 7.30.0 to and including 8.20.0 Not affected versions: curl < 7.30.0 and >= 8.21.0 Introduced-in: https://github.com/curl/curl/commit/a1701eea289fe7ea8065 STARTTLS support was introduced in curl via a number of separate commits for the different protocols. The specific commit mentioned above did not introduce the problem for all the protocols at once. 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 curl 8.21.0 fixes this logical flaw Fixed-in: https://github.com/curl/curl/commit/a86efdd7ca5433de9231e6 RECOMMENDATIONS We suggest you take one of the following actions immediately, in order of preference: A - Upgrade to curl and libcurl 8.21.0 B - Apply the patch and rebuild libcurl C - Do not use clear-text IMAP/POP3/SMTP/FTP/LDAP transfers TIMELINE It was reported to the curl project on May 6 2026. We contacted distros@openwall on June 17 2026. libcurl 8.21.0 was released on June 24 2026, coordinated with the publication of this advisory. CREDITS Reported-by: Andrew Nesbitt (powered by Mythos) Patched-by: Stefan Eissing Thanks a lot! _____________________________________________________________________ CVE-2026-8458 wrong reuse for different services Project curl Security Advisory, June 24 2026 VULNERABILITY libcurl might in some circumstances reuse the wrong connection when asked to do Negotiate-authenticated ones, even when they are set to use different "services". libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criteria must be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different services. INFO The intended service to use for Negotiate is set with CURLOPT_SERVICE_NAME or CURLOPT_PROXY_SERVICE_NAME. This flaw still only triggers while using the same hostname, port number and credentials and the previous connection is still found alive in the connection pool. The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2026-8458 to this issue. This flaw is similar to CVE-2026-5545. CWE-488: Exposure of Data Element to Wrong Session Severity: Low AFFECTED VERSIONS This flaw has existed since curl started to support setting the service name for Negotiate. Affected versions: from curl 7.43.0 to and including 8.20.0 Not affected versions: curl < 7.43.0 and >= 8.21.0 Introduced-in: https://github.com/curl/curl/commit/97c272e5d173ad5f706 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 curl 8.21.0 makes sure that connection reuse take the service name into account. Fixed-in: https://github.com/curl/curl/commit/5e99b73cf441d9c369768b9cd RECOMMENDATIONS We suggest you take one of the following actions immediately, in order of preference: A - Upgrade to curl and libcurl 8.21.0 B - Apply the patch and rebuild libcurl C - Avoid using HTTP Negotiate in your application TIMELINE It was reported to the curl project on May 8 2026. We contacted distros@openwall on June 17 2026. libcurl 8.21.0 was released on June 24 2026, coordinated with the publication of this advisory. CREDITS Reported-by: Muhamad Arga Reksapati Patched-by: Stefan Eissing Thanks a lot! _____________________________________________________________________ CVE-2026-8924 trailing dot domain super cookie Project curl Security Advisory, June 24 2026 VULNERABILITY A flaw in curl’s cookie parsing logic allows a malicious HTTP server to set "super cookies" that bypass the Public Suffix List check. This enables an attacker-controlled origin to inject cookies that curl subsequently scopes and transmits to unrelated third-party domains. INFO The attacker would do this by setting the cookie for a domain using a trailing dot (for example like domain=co.uk.) when a trailing dot hostname is used in the URL curl works with (for example https://example.co.uk.. When curl is built without PSL support, it cannot protect against this problem but it is expected to not allow "too wide" cookies when PSL support is enabled. Trailing dots in hostnames is a menace and a plague that keeps haunting us and the world at large. It is not commonly used and the trailing dot cannot be passed in the TLS SNI fields, which makes them hard to inter-operate with. The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2026-8924 to this issue. CWE-201: Information Exposure Through Sent Data Severity: Low AFFECTED VERSIONS Affected versions: curl 7.46.0 to and including 8.20.0 Not affected versions: curl < 7.46.0 and >= 8.21.0 Introduced-in: https://github.com/curl/curl/commit/e77b5b7453c1e8c libcurl is used by many applications, but not always advertised as such! This flaw is also accessible using the curl command line tool. SOLUTION Fixed-in: https://github.com/curl/curl/commit/51beed175dbfc37da3113f6acc RECOMMENDATIONS A - Upgrade curl to version 8.21.0 B - Apply the patch to your local version C - Do not use trailing dots on hostnames TIMELINE This issue was reported to the curl project on May 13, 2026. We contacted distros@openwall on June 17, 2026. curl 8.21.0 was released on June 24 2026, coordinated with the publication of this advisory. CREDITS Reported-by: vegagent on hackerone Patched-by: Daniel Stenberg Thanks a lot! _____________________________________________________________________ CVE-2026-8925 SASL double-free Project curl Security Advisory, June 24 2026 VULNERABILITY The curl logic that works with SASL authentication could end up cleaning up the GSASL context twice without clearing the pointer in between, making it free() the same pointer twice. INFO This flaw can trigger with protocols using SASL: IMAP, POP3, SMTP and IMAP if curl was built to use libgsasl. We deem it hard for an attacker to control or otherwise affect exactly which memory the second free() call frees, but we cannot rule out that in limited situation could be used for nefarious purposes as the sequence and timing can be somewhat affected by server behavior. The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2026-8925 to this issue. CWE-415: Double Free Severity: Medium AFFECTED VERSIONS Affected versions: curl 8.15.0 to and including 8.20.0 Not affected versions: curl < 8.15.0 and >= 8.21.0 Introduced-in: https://github.com/curl/curl/commit/ab650379a8c25ca952f6 libcurl is used by many applications, but not always advertised as such! This bug is considered a C mistake. It is likely to have been avoided had we not been using C. This flaw is also accessible using the curl command line tool. SOLUTION Fixed-in: https://github.com/curl/curl/commit/3da249e1f0716c06644ed3522 RECOMMENDATIONS A - Upgrade curl to version 8.21.0 B - Apply the patch to your local version C - Do not use IMAP, POP3, SMTP or IMAP TIMELINE This issue was reported to the curl project on May 14, 2026. We contacted distros@openwall on June 17, 2026. curl 8.21.0 was released on June 24 2026, coordinated with the publication of this advisory. CREDITS Reported-by: Joshua Rogers (Aisle Research) Patched-by: Viktor Szakats Thanks a lot! _____________________________________________________________________ CVE-2026-8926 password leak with netrc and user in URL Project curl Security Advisory, June 24 2026 VULNERABILITY When asking curl to use a .netrc file to find credentials and at the same time specifying a URL with a username (without a password), like https://user@example.com/, curl could wrongly get and use the password for another user set in the .netrc file for that host if such a one exists and there is no match for the specified user. INFO The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2026-8926 to this issue. CWE-522: Insufficiently Protected Credentials Severity: Low AFFECTED VERSIONS Affected versions: curl 8.11.1 to and including 8.20.0 Not affected versions: curl < 8.11.1 and >= 8.21.0 Introduced-in: https://github.com/curl/curl/commit/e9b9bbac22c26cf67 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 is also accessible using the curl command line tool. SOLUTION Fixed-in: https://github.com/curl/curl/commit/4ae1d7cc2643e47 RECOMMENDATIONS A - Upgrade curl to version 8.21.0 B - Apply the patch to your local version C - Do not use netrc for authentication data TIMELINE This issue was reported to the curl project on May 14, 2026. We contacted distros@openwall on June 17, 2026. curl 8.21.0 was released on June 24 2026, coordinated with the publication of this advisory. CREDITS Reported-by: Joshua Rogers (Aisle Research) Patched-by: Stefan Eissing Thanks a lot! _____________________________________________________________________ CVE-2026-8927 env-set cross-proxy Digest auth state leak Project curl Security Advisory, June 24 2026 VULNERABILITY When reusing a libcurl handle for sequential transfers driven by environment-variable proxy configuration, libcurl fails to clear the proxy authentication state between requests. Specifically, if the initial transfer authenticates against proxyA using Digest auth, a subsequent transfer routed through proxyB erroneously leaks the Proxy-Authorization: header intended solely for proxyA. INFO An evil proxyB could use this incoming request header field to impersonate the client in communicating with proxyA, as the header contains the authenticated state. There is nothing in the request details passed to proxyB that reveal the name or the address of proxyA, which mitigates this problem. This flaw is almost identical to CVE-2026-7168. The difference lies primarily in how the proxy is selected. This bug is not considered a C mistake (likely to have been avoided had we not been using C). This flaw does not affect the curl command line tool. The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2026-8927 to this issue. CWE-294: Authentication Bypass by Capture-replay Severity: Medium AFFECTED VERSIONS Affected versions: curl 7.12.0 to and including 8.20.0 Not affected versions: curl < 7.12.0 and >= 8.21.0 Introduced-in: https://github.com/curl/curl/commit/fc6eff13b5414caf6edf libcurl is used by many applications, but not always advertised as such! SOLUTION Fixed-in: https://github.com/curl/curl/commit/5c225384b8d52c6 RECOMMENDATIONS We suggest you take one of the following actions immediately, in order of preference: A - Upgrade curl and libcurl to version 8.21.0 B - Apply the patch to your version and rebuild C - Avoid reusing handles when changing proxies TIMELINE This issue was reported to the curl project on May 18, 2026. curl 8.21.0 was released on June 24 2026, coordinated with the publication of this advisory. CREDITS Reported-by: Ady Elouej Patched-by: Daniel Stenberg Thanks a lot! _____________________________________________________________________ CVE-2026-8932 incomplete mTLS config matching in conn reuse Project curl Security Advisory, June 24 2026 Permalink VULNERABILITY libcurl would reuse a previously created connection even when some mTLS config related option had been changed that should have prohibited reuse. libcurl keeps previously used connections in a connection pool for subsequent transfers to reuse if one of them matches the setup. However, some TLS settings related to client certificates were left out from the configuration match checks, making them match too easily. In particular options related to the private key. INFO This flaw is similar to CVE-2022-27782. This bug is not considered a C mistake (likely to have been avoided had we not been using C). This flaw does not affect the curl command line tool. The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2026-8932 to this issue. CWE-305: Authentication Bypass by Primary Weakness Severity: Low AFFECTED VERSIONS Affected versions: curl 7.7 to and including 8.20.0 Not affected versions: curl < 7.7 and >= 8.21.0 Introduced-in: https://github.com/curl/curl/commit/a1d6ad26100bc493c7b0 libcurl is used by many applications, but not always advertised as such! SOLUTION Fixed-in: https://github.com/curl/curl/commit/7541ae569d82fb308a5e2d94 RECOMMENDATIONS We suggest you take one of the following actions immediately, in order of preference: A - Upgrade curl and libcurl to version 8.21.0 B - Apply the patch to your version and rebuild C - Avoid reusing handles when changing client cert details TIMELINE This issue was reported to the curl project on May 13, 2026. curl 8.21.0 was released on June 24 2026, coordinated with the publication of this advisory. CREDITS Reported-by: Joshua Rogers (Aisle Research) Patched-by: Joshua Rogers (Aisle Research) Thanks a lot! _____________________________________________________________________ CVE-2026-9079 stale proxy password leak Project curl Security Advisory, June 24 2026 VULNERABILITY libcurl had a flaw that when instructed to clear proxy authentication credentials which made it not do so, leaving the old credentials around to get used for subsequent transfers that should not know nor use them. INFO This bug is not considered a C mistake (likely to have been avoided had we not been using C). This flaw does not affect the curl command line tool. The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2026-9079 to this issue. CWE-522: Insufficiently Protected Credentials Severity: Medium AFFECTED VERSIONS Affected versions: curl 8.8.0 to and including 8.20.0 Not affected versions: curl < 8.8.0 and >= 8.21.0 Introduced-in: https://github.com/curl/curl/commit/d5e83eb745762f48d8f libcurl is used by many applications, but not always advertised as such! SOLUTION Fixed-in: https://github.com/curl/curl/commit/88c7e16cceec816a2df45c89 RECOMMENDATIONS We suggest you take one of the following actions immediately, in order of preference: A - Upgrade curl and libcurl to version 8.21.0 B - Apply the patch to your version and rebuild C - Avoid reusing handles when changing proxy credentials TIMELINE This issue was reported to the curl project on May 20, 2026. curl 8.21.0 was released on June 24 2026, coordinated with the publication of this advisory. CREDITS XlabAI Team of Tencent Xuanwu Lab Reported-by: Guannan Wang Reported-by: Zhanpeng Liu Reported-by: Jiashuo Liang Reported-by: Guancheng Li Patched-by: Daniel Stenberg Thanks a lot! _____________________________________________________________________ CVE-2026-9080 UAF after pause in socket callback Project curl Security Advisory, June 24 2026 VULNERABILITY Calling curl_easy_pause() within the event-based CURLMOPT_SOCKETFUNCTION callback triggers a use-after-free vulnerability, where libcurl attempts to store a flag using a dangling struct pointer immediately after that pointer's memory has been freed. INFO This bug is considered a C mistake (likely to have been avoided had we not been using C). This flaw does not affect the curl command line tool. The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2026-9080 to this issue. CWE-416: Use After Free Severity: Low AFFECTED VERSIONS Affected versions: curl 8.13.0 to and including 8.20.0 Not affected versions: curl < 8.13.0 and >= 8.21.0 Introduced-in: https://github.com/curl/curl/commit/cfc657a48d libcurl is used by many applications, but not always advertised as such! SOLUTION Fixed-in: https://github.com/curl/curl/commit/5ab34cba42e4ee4282fe RECOMMENDATIONS We suggest you take one of the following actions immediately, in order of preference: A - Upgrade curl and libcurl to version 8.21.0 B - Apply the patch to your version and rebuild C - Avoid pausing within the socket callback TIMELINE This issue was reported to the curl project on May 19, 2026. curl 8.21.0 was released on June 24 2026, coordinated with the publication of this advisory. CREDITS Reported-by: Joshua Rogers (Aisle Research) Patched-by: Joshua Rogers (Aisle Research) Patched-by: Daniel Stenberg Thanks a lot! _____________________________________________________________________ CVE-2026-9545 exposing HTTP/3 early data Project curl Security Advisory, June 24 2026 VULNERABILITY In this scenario, libcurl first uses a proper HTTP/3 server for the initial transfers, and when it makes a second transfer to the same site it has been replaced by the attacker's impostor machine - without a valid certificate. When libcurl returns to the hostname the second time with a cached SSL session (CURLOPT_SSL_SESSIONID_CACHE is not disabled) and early data enabled (the CURLSSLOPT_EARLYDATA bit is set in CURLOPT_SSL_OPTIONS), libcurl might send off the second request's bytes on that new connection before enforcing the certificate verification failure. Potentially leaking sensitive information. INFO This flaw is HTTP/3 specific (and only for the ngtcp2 + nghttp3 backend), which is only used for HTTPS:// URLs. This bug is not considered a C mistake (not likely to have been avoided had we not been using C). This flaw also affects the curl command line tool. The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2026-9545 to this issue. CWE-200: Exposure of Sensitive Information to an Unauthorized Actor Severity: Low AFFECTED VERSIONS Affected versions: curl 8.11.0 to and including 8.20.0 Not affected versions: curl < 8.11.0 and >= 8.21.0 Introduced-in: https://github.com/curl/curl/commit/962097b8dd44ed5b9 libcurl is used by many applications, but not always advertised as such! SOLUTION Fixed-in: https://github.com/curl/curl/commit/7b9613fa9b1a5e04301a39 RECOMMENDATIONS We suggest you take one of the following actions immediately, in order of preference: A - Upgrade curl and libcurl to version 8.21.0 B - Apply the patch to your version and rebuild C - Avoid using TLS early data TIMELINE This issue was reported to the curl project on May 19, 2026. curl 8.21.0 was released on June 24 2026, coordinated with the publication of this advisory. CREDITS Reported-by: Eunsoo Kim (Autonomous Code Security team at Microsoft) Patched-by: Stefan Eissing Thanks a lot! _____________________________________________________________________ CVE-2026-9546 sending old referer Project curl Security Advisory, June 24 2026 VULNERABILITY A vulnerability in libcurl caused the HTTP Referer: header to persist even when explicitly cleared. While the documentation states that passing NULL to CURLOPT_REFERER suppresses the header, the option failed to clear the internal state. As a result, the previous referrer string was erroneously reused and sent in subsequent requests, potentially leaking sensitive information to unintended servers. INFO This bug is not considered a C mistake (not likely to have been avoided had we not been using C). This flaw does not affect the curl command line tool. The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2026-9546 to this issue. CWE-200: Exposure of Sensitive Information to an Unauthorized Actor Severity: Low AFFECTED VERSIONS Affected versions: curl 8.18.0 to and including 8.20.0 Not affected versions: curl < 8.18.0 and >= 8.21.0 Introduced-in: https://github.com/curl/curl/commit/2cb868242dc2ac9cd5 libcurl is used by many applications, but not always advertised as such! SOLUTION Fixed-in: https://github.com/curl/curl/commit/862e8a74a84478d82973471 RECOMMENDATIONS We suggest you take one of the following actions immediately, in order of preference: A - Upgrade curl and libcurl to version 8.21.0 B - Apply the patch to your version and rebuild C - Avoid using CURLOPT_REFERER TIMELINE This issue was reported to the curl project on May 22, 2026. curl 8.21.0 was released on June 24 2026, coordinated with the publication of this advisory. CREDITS Reported-by: renjian on hackerone Patched-by: Daniel Stenberg Thanks a lot! _____________________________________________________________________ CVE-2026-11856 cross-origin Digest auth state leak Project curl Security Advisory, June 24 2026 VULNERABILITY Successfully using libcurl to do a transfer to a specific HTTP origin (hostA) with Digest authentication and then changing the origin to a different one (hostB) for a second transfer, reusing the same handle, makes libcurl wrongly pass on the Authorization: header field meant for hostA, to hostB. INFO An evil hostB could use this incoming request header field to impersonate the client in communicating with hostA, as the header contains the authenticated state. There is nothing in the request details passed to hostB that reveal the name or the address of hostA, which mitigates this problem. Also, since the credentials are not exposed, a malicious actor can only repeat the single specific request for that exact path. This flaw is similar to CVE-2026-7168 but for host authentication instead of proxy. This bug is not considered a C mistake (likely to have been avoided had we not been using C). This flaw does not affect the curl command line tool. The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2026-11856 to this issue. CWE-294: Authentication Bypass by Capture-replay Severity: Medium AFFECTED VERSIONS Affected versions: curl 7.10.6 to and including 8.20.0 Not affected versions: curl < 7.10.6 and >= 8.21.0 Introduced-in: https://github.com/curl/curl/commit/334d78cd18a7310144383 libcurl is used by many applications, but not always advertised as such! SOLUTION Fixed-in: https://github.com/curl/curl/commit/5c6b4880357ab3e72967c1c45c RECOMMENDATIONS We suggest you take one of the following actions immediately, in order of preference: A - Upgrade curl and libcurl to version 8.21.0 B - Apply the patch to your version and rebuild C - Avoid reusing handles when changing origin TIMELINE This issue was reported to the curl project on June 10, 2026. curl 8.21.0 was released on June 24 2026, coordinated with the publication of this advisory. CREDITS Reported-by: jjchuck on hackerone Patched-by: Daniel Stenberg 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 + =========================================================