This update upgrades curl to version 8.18.0-alt1. Security Fix(es): * CVE-2025-13034: When using `CURLOPT_PINNEDPUBLICKEY` option with libc…
This update upgrades curl to version 8.18.0-alt1. Security Fix(es): * CVE-2025-13034: 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 verification. * CVE-2025-14017: When doing multi-threaded 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. * CVE-2025-14524: 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 the bearer token to the new target host. * CVE-2025-14819: When doing TLS related transfers with reused 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. * CVE-2025-15079: When doing SSH-based transfers using either SCP or SFTP, and setting the known_hosts 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* known_hosts file. * CVE-2025-15224: 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.
The product does not validate, or incorrectly validates, a certificate.
https://cwe.mitre.org/data/definitions/295.html →Open in CWE collection →An adversary exploits a weakness resulting from using a hashing algorithm with weak collision resistance to generate certificate signing requests (CSR) that contain collision blocks in their "to be signed" parts. The adversary submits one CSR to be signed by a trusted certificate authority then uses the signed blob to make a second certificate appear signed by said certificate authority. Due to the hash collision, both certificates, though different, hash to the same value and so the signed blob works just as well in the second certificate. The net effect is that the adversary's second X.509 certificate, which the Certification Authority has never seen, is now signed and validated by that Certification Authority.
https://capec.mitre.org/data/definitions/459.html →Open in CAPEC collection →An adversary exploits a cryptographic weakness in the signature verification algorithm implementation to generate a valid signature without knowing the key.
https://capec.mitre.org/data/definitions/475.html →Open in CAPEC collection →| Product | Vendor | Status |
|---|---|---|
| Tracked | ||
| curl | Tracked | |
| curl | Tracked | |
| curl | Tracked | |
| curl | Tracked | |
| curl | Tracked | |
| curl | Tracked | |
| curl | Tracked | |
| curl | Tracked | |
| curl | Tracked | |
| libcurl | Tracked | |
| libcurl-devel | Tracked | |
| curl | * | Tracked |
| curl | Tracked | |
| curl | Tracked | |
| libcurl | Tracked | |
| libcurl | Tracked | |
| libcurl-devel | Tracked | |
| libcurl-devel | Tracked |