CVE-2025-13034
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2026-01-08

Last updated on: 2026-01-20

Assigner: curl

Description
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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-01-08
Last Modified
2026-01-20
Generated
2026-05-07
AI Q&A
2026-01-08
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
haxx curl From 8.8.0 (inc) to 8.18.0 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-295 The product does not validate, or incorrectly validates, a certificate.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

CVE-2025-13034 is a medium-severity vulnerability in curl versions 8.8.0 through 8.17.0 where the public key pinning check is improperly skipped when using the CURLOPT_PINNEDPUBLICKEY option in libcurl or the --pinnedpubkey option in the curl tool. This happens specifically when connecting over QUIC using the ngtcp2 backend built with GnuTLS, and the user explicitly disables standard certificate verification. As a result, curl may allow connections without verifying the server's public key, potentially accepting impostor servers. [1, 2]


How can this vulnerability impact me? :

This vulnerability can allow an attacker to impersonate a legitimate server by bypassing the public key pinning verification in curl when certain conditions are met (QUIC with ngtcp2 using GnuTLS and disabled standard certificate verification). This could lead to man-in-the-middle attacks where sensitive data might be intercepted or altered, compromising the security of communications relying on curl for secure connections. [1, 2]


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation steps include upgrading curl to version 8.18.0 or later where the vulnerability is fixed, building curl with a different TLS library than GnuTLS for ngtcp2, or avoiding the use of HTTP/3 (QUIC) connections that trigger the issue. [1]


How can this vulnerability be detected on my network or system? Can you suggest some commands?

To detect this vulnerability on your system, check if you are using curl versions 8.8.0 through 8.17.0 with QUIC connections via ngtcp2 built with GnuTLS, and if the CURLOPT_PINNEDPUBLICKEY or --pinnedpubkey option is used while standard certificate verification is disabled. You can verify your curl version by running: `curl --version`. To check if QUIC with ngtcp2 and GnuTLS is enabled, inspect the curl build info with `curl -V` and look for 'ngtcp2' and 'GnuTLS' in the features list. Since the vulnerability involves skipping the public key pinning check when standard verification is disabled, review your curl commands or libcurl usage for the presence of `--pinnedpubkey` or `CURLOPT_PINNEDPUBLICKEY` combined with disabled certificate verification (e.g., `--insecure` or `CURLOPT_SSL_VERIFYPEER` set to 0). There are no specific network detection commands provided, but auditing your curl usage and versions as described can help identify vulnerable setups. [1, 2]


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart