Hiroki Kurosawa

**Name of the Vulnerable Software and Affected Versions** libcurl (affected versions not specified) **Description** The issue arises from an omission in libcurl's support for pinning the server certificate public key for HTTPS transfers when using QUIC for HTTP/3 with the wolfSSL TLS backend. Although the documentation suggests that this option works with wolfSSL, it fails to specify that the check is not performed in the context of QUIC and HTTP/3. As a result, users may unwittingly connect to an impostor server without noticing, since the transfer will succeed if the pin is fine. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** libcurl (affected versions not specified) **Description** The issue occurs when libcurl establishes a QUIC connection to a host specified as an IP address in the URL, resulting in the accidental skipping of certificate verification. This failure to verify certificates makes it impossible to detect impostors or man-in-the-middle attacks. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

Name of the Vulnerable Software and Affected Versions: curl versions prior to 8.10.0 Description: The issue is related to the improper validation of server certificates when using the Certificate Status Request TLS extension, also known as OCSP stapling. If the returned status reports an error other than 'revoked', such as 'unauthorized', it is not treated as a bad certificate. This could potentially allow for man-in-the-middle attacks due to improper validation. Recommendations: For curl versions prior to 8.10.0, upgrade to version 8.10.0 or later to resolve the issue. As a temporary workaround, consider disabling the use of OCSP stapling until a patch is available. Restrict access to sensitive data and minimize the risk of exploitation by avoiding the use of vulnerable curl versions for critical operations.

**Name of the Vulnerable Software and Affected Versions** curl (affected versions not specified) **Description** The issue is related to a flaw in curl where it inadvertently keeps the SSL session ID for connections in its cache even when the verify status (OCSP stapling) test failed. This allows a subsequent transfer to the same hostname to succeed if the session ID cache is still fresh, skipping the verify status check. There is no information provided about the estimated number of potentially affected devices worldwide or real-world incidents where this issue was exploited. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** curl versions prior to 8.1.0 **Description** The issue is related to improper certificate validation in the way curl supports matching of wildcard patterns when listed as "Subject Alternative Name" in TLS server certificates. This could lead to incorrect matching of IDN hosts and potentially allow patterns that should mismatch. IDN hostnames are converted to puny code before being used for certificate checks, but the wildcard check in curl could still incorrectly match patterns. This could result in a remote attacker being able to perform a "man-in-the-middle" attack. **Recommendations** For versions prior to 8.1.0, update to version 8.1.0 or later to resolve the issue. As a temporary workaround, consider disabling the use of wildcard patterns in TLS server certificates until a patch is available. Restrict access to IDN hostnames to minimize the risk of exploitation. Avoid using the `xn--` prefix in wildcard patterns to prevent incorrect matching.

**Name of the Vulnerable Software and Affected Versions** curl versions prior to 8.1.0 **Description** An information disclosure issue exists when doing HTTP(S) transfers, where libcurl might erroneously use the read callback (`CURLOPT READFUNCTION`) to ask for data to send, even when the `CURLOPT POSTFIELDS` option has been set. This occurs if the same handle previously was used to issue a `PUT` request which used that callback. The flaw may cause the application to misbehave, sending off the wrong data or using memory after free in the second transfer. The problem exists in the logic for a reused handle when it is changed from a `PUT` to a `POST`. **Recommendations** For versions prior to 8.1.0, update to version 8.1.0 or later to resolve the issue. As a temporary workaround, consider avoiding the reuse of handles for `PUT` and `POST` requests, or disabling the `CURLOPT READFUNCTION` callback when switching from `PUT` to `POST` to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** curl versions 7.77.0 through 7.85.0 **Description** The issue is related to the HSTS check in curl, which can be bypassed to trick it into staying with HTTP. This can happen when the host name in the given URL uses IDN characters that get replaced with ASCII counterparts as part of the IDN conversion. For example, using the character UTF-8 U+3002 (IDEOGRAPHIC FULL STOP) instead of the common ASCII full stop of U+002E (.). The earliest affected version is 7.77.0. **Recommendations** For versions 7.77.0 through 7.85.0, update to version 7.86.0 to resolve the issue. As a temporary workaround, consider avoiding the use of IDN characters in URLs until the issue is resolved. Restrict access to sensitive information to minimize the risk of exploitation.