CVE-2025-13034: libcurl Information Disclosure Vulnerability

CVE-2025-13034 Overview

CVE-2025-13034 is a certificate validation bypass vulnerability affecting cURL and libcurl when using public key pinning with specific QUIC configurations. When utilizing the CURLOPT_PINNEDPUBLICKEY option in libcurl or the --pinnedpubkey command-line option in curl, the application should verify the server's public key against the pinned value to protect against impersonation attacks. However, under certain conditions, this critical security check was bypassed, potentially allowing connections to malicious servers without proper verification.

The vulnerability occurs specifically when QUIC connections are made using ngtcp2 built with GnuTLS as the TLS backend, combined with the user explicitly disabling standard certificate verification. Under these conditions, the public key pinning check is skipped entirely, leaving the connection vulnerable to man-in-the-middle attacks.

Critical Impact

Attackers could impersonate legitimate servers by exploiting this public key pinning bypass, potentially intercepting or manipulating sensitive data transmitted over what users believe are secured connections.

Affected Products

• cURL with QUIC support via ngtcp2 (built with GnuTLS)
• libcurl with QUIC support via ngtcp2 (built with GnuTLS)
• Applications utilizing libcurl with the affected configuration

Discovery Timeline

• 2026-01-08 - CVE-2025-13034 published to NVD
• 2026-01-08 - Last updated in NVD database

Technical Details for CVE-2025-13034

Vulnerability Analysis

This vulnerability falls under CWE-295 (Improper Certificate Validation), which represents a failure to properly verify that a certificate belongs to the expected entity. The issue specifically affects the public key pinning mechanism in cURL/libcurl when using QUIC protocol connections.

Public key pinning is an additional layer of security that allows applications to specify which public keys should be trusted for a particular server, providing protection even if a certificate authority is compromised. When this check is bypassed, the fundamental security guarantee of pinning is broken.

The vulnerability requires a specific combination of factors to be exploitable: the connection must use QUIC protocol via the ngtcp2 library, ngtcp2 must be compiled to use GnuTLS as its TLS backend, and the user must have explicitly disabled standard certificate verification (typically via CURLOPT_SSL_VERIFYPEER set to false or --insecure flag). While this combination of requirements limits the attack surface, environments meeting these criteria are vulnerable to server impersonation attacks.

Root Cause

The root cause lies in the code path handling QUIC connections when ngtcp2 is built with GnuTLS. Under this specific configuration, when standard certificate verification is disabled by the user, the code fails to execute the public key pinning verification routine. This creates a scenario where neither standard certificate validation nor public key pinning provides protection, completely undermining connection security.

Attack Vector

This vulnerability is exploitable over the network without requiring authentication or user interaction, though it requires specific client-side configuration to trigger. An attacker positioned to perform a man-in-the-middle attack could:

1. Intercept QUIC connection attempts from vulnerable clients
2. Present a fraudulent server certificate with a different public key
3. Establish a connection that would normally be rejected by public key pinning
4. Intercept, modify, or inject data into the communication stream

The attack is particularly insidious because users who have implemented public key pinning believe they have an additional layer of security protecting their connections, when in fact this protection is absent under the vulnerable configuration.

Detection Methods for CVE-2025-13034

Indicators of Compromise

• Unexpected TLS certificate warnings or changes in certificate fingerprints for monitored endpoints
• QUIC connections completing successfully despite public key mismatches when logging is enabled
• Network traffic to expected endpoints showing different certificate chains than previously observed
• Log entries indicating disabled certificate verification in combination with QUIC/ngtcp2 usage

Detection Strategies

• Audit application configurations for use of CURLOPT_PINNEDPUBLICKEY or --pinnedpubkey in combination with disabled certificate verification
• Review build configurations to identify ngtcp2 installations compiled with GnuTLS backend
• Implement network monitoring to detect unexpected certificate changes on pinned connections
• Deploy application-level logging to track certificate validation outcomes for QUIC connections

Monitoring Recommendations

• Enable verbose cURL logging in development and staging environments to verify pinning behavior
• Monitor for connections where certificate verification is explicitly disabled in production systems
• Implement alerting on certificate pinning validation failures or bypasses in application logs
• Track cURL/libcurl version deployments across infrastructure to identify affected installations

How to Mitigate CVE-2025-13034

Immediate Actions Required

• Update cURL and libcurl to the latest patched version as soon as available
• Audit all applications using libcurl with public key pinning to identify vulnerable configurations
• Re-enable standard certificate verification where it has been disabled, unless absolutely necessary
• Consider temporarily switching to alternative TLS backends if using ngtcp2 with GnuTLS

Patch Information

The cURL project has published security advisories for this vulnerability. Refer to the official cURL CVE-2025-13034 Advisory for specific patch versions and detailed remediation guidance. Additional technical details are available in the CVE-2025-13034 JSON documentation.

Workarounds

• Avoid disabling standard certificate verification (CURLOPT_SSL_VERIFYPEER or --insecure) when using public key pinning with QUIC connections
• If certificate verification must be disabled, avoid using QUIC protocol or switch to an alternative QUIC backend not affected by this issue
• Use ngtcp2 built with OpenSSL instead of GnuTLS as an interim measure
• Implement additional application-layer verification of server identity where feasible

# Configuration example - Verify cURL is using secure settings
# Check cURL build configuration for QUIC backend
curl --version | grep -i "ngtcp2\|quic\|gnutls"

# If using libcurl programmatically, ensure certificate verification is enabled
# when using public key pinning:
# curl_easy_setopt(curl, CURLOPT_SSL_VERIFYPEER, 1L);
# curl_easy_setopt(curl, CURLOPT_PINNEDPUBLICKEY, "sha256//...");