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.

Nome do software vulnerável e versões afetadas: versões do curl anteriores à 8.10.0 Descrição: O problema está relacionado à validação inadequada de certificados de servidor ao usar a extensão TLS Certificate Status Request, também conhecida como OCSP stapling. Se o status retornado relatar um erro diferente de “revogado”, como “não autorizado”, ele não é tratado como um certificado inválido. Isso poderia potencialmente permitir ataques man-in-the-middle devido à validação inadequada. Recomendações: Para versões do curl anteriores à 8.10.0, atualize para a versão 8.10.0 ou posterior para resolver o problema. Como solução alternativa temporária, considere desativar o uso do OCSP stapling até que um patch esteja disponível. Restrinja o acesso a dados confidenciais e minimize o risco de exploração evitando o uso de versões vulneráveis do curl para operações críticas.

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

**Nome do software vulnerável e versões afetadas** Versões do curl de 7.77.0 a 7.85.0 **Descrição** O problema está relacionado à verificação HSTS no curl, que pode ser contornada para induzir o programa a permanecer na conexão HTTP. Isso pode ocorrer quando o nome do host na URL fornecida utiliza caracteres IDN que são substituídos por seus equivalentes ASCII como parte da conversão IDN. Por exemplo, ao usar o caractere UTF-8 U+3002 (PONTO IDEOGRÁFICO) em vez do ponto ASCII comum U+002E (.). A versão mais antiga afetada é a 7.77.0. **Recomendações** Para as versões 7.77.0 a 7.85.0, atualize para a versão 7.86.0 para resolver o problema. Como solução alternativa temporária, considere evitar o uso de caracteres IDN em URLs até que o problema seja resolvido. Restrinja o acesso a informações confidenciais para minimizar o risco de exploração.