CVE-2025-5025: Haxx Curl Information Disclosure Flaw

CVE-2025-5025 Overview

CVE-2025-5025 affects libcurl's public key pinning feature when used with QUIC for HTTP/3 transfers backed by wolfSSL. The library fails to perform the pin check during these connections, silently bypassing a security control that users explicitly configure. Documentation states the pinning option works with wolfSSL but does not warn that QUIC and HTTP/3 are excluded. Applications relying on pinning to detect impostor servers receive successful connections with no indication of the missing validation. The flaw is categorized as Improper Certificate Validation [CWE-295].

Critical Impact

Public key pinning silently fails for HTTP/3 transfers using wolfSSL, allowing connections to impostor servers without warning users or applications.

Affected Products

• Haxx curl (libcurl) builds compiled with wolfSSL as the TLS backend
• Applications using CURLOPT_PINNEDPUBLICKEY with HTTP/3 (QUIC) transfers
• Downstream distributions and software embedding vulnerable libcurl versions

Discovery Timeline

• 2025-05-28 - CVE CVE-2025-5025 published to NVD
• 2025-07-30 - Last updated in NVD database

Technical Details for CVE-2025-5025

Vulnerability Analysis

libcurl exposes CURLOPT_PINNEDPUBLICKEY so applications can pin the expected server certificate public key. When the pin matches the key presented during the TLS handshake, the transfer proceeds. When it does not match, libcurl aborts the connection. This control defends against certificate authority compromise and rogue intermediates.

The defect lies in the QUIC/HTTP/3 code path when wolfSSL is the active TLS backend. The pin comparison logic is not invoked during the QUIC TLS handshake. The transfer succeeds regardless of whether the server's public key matches the configured pin. Applications that depend on the pin as their primary trust anchor lose that protection without any error, log entry, or return code change.

Documentation reinforced the false expectation by listing wolfSSL as a supported backend for the pinning feature without noting the QUIC limitation. Developers auditing their code against the documentation would conclude pinning was enforced.

Root Cause

The omission is a missing certificate validation step [CWE-295] in the wolfSSL QUIC integration. The standard TLS code path executes the pin comparison routine, but the QUIC handshake handler does not call the equivalent routine before declaring the connection trusted.

Attack Vector

An attacker positioned to intercept HTTP/3 traffic, for example through DNS manipulation, BGP hijacking, or compromise of a certificate authority, can present a different certificate to a victim using libcurl with wolfSSL. The attacker must still satisfy standard TLS chain validation, which raises exploitation complexity. Once chain validation succeeds, the missing pin check allows the impostor connection to complete normally. The client application receives data from the attacker-controlled endpoint while believing the pin enforced its identity guarantee.

No verified public exploit or proof-of-concept code is available. See the cURL CVE-2025-5025 Documentation for the vendor's technical description.

Detection Methods for CVE-2025-5025

Indicators of Compromise

• Unexpected HTTP/3 connections from libcurl-based clients to hosts that should be blocked by a configured pin
• TLS handshakes succeeding to servers presenting certificates that do not match documented pin values
• Application logs showing successful transfers where pin enforcement should have aborted the session

Detection Strategies

• Inventory builds of curl and libcurl to identify which were compiled with wolfSSL and HTTP/3 support, using curl -V to confirm the TLS backend and HTTP3 feature flag
• Audit applications that set CURLOPT_PINNEDPUBLICKEY and verify whether they negotiate HTTP/3, since these combinations are exposed to the flaw
• Run integration tests that intentionally present a mismatched certificate over HTTP/3 to confirm whether the client correctly rejects the connection

Monitoring Recommendations

• Log the negotiated ALPN protocol and TLS backend for outbound libcurl transfers to identify HTTP/3 sessions
• Alert on libcurl HTTP/3 connections to sensitive endpoints when the deployed library version is known vulnerable
• Track package versions of curl and wolfSSL across the fleet so unpatched hosts are visible to the security team

How to Mitigate CVE-2025-5025

Immediate Actions Required

• Upgrade libcurl to the fixed version published in the cURL CVE-2025-5025 Documentation advisory
• Identify all applications using CURLOPT_PINNEDPUBLICKEY with wolfSSL and validate whether they negotiate HTTP/3
• Until patches are deployed, disable HTTP/3 negotiation in affected applications so transfers fall back to HTTP/1.1 or HTTP/2 where pinning is enforced

Patch Information

The curl project published the fix and details at the cURL CVE-2025-5025 Documentation page. Machine-readable metadata is available in the cURL CVE-2025-5025 JSON Data file. Additional discussion is available in the HackerOne Report #3153497 and the Openwall OSS-Security Discussion.

Workarounds

• Rebuild libcurl against a TLS backend other than wolfSSL, such as OpenSSL, when pinning with HTTP/3 is required
• Force HTTP/2 or HTTP/1.1 by setting CURLOPT_HTTP_VERSION to a non-HTTP/3 value in calling applications
• Add an application-level certificate or public key check after the transfer completes to compensate for the missing libcurl enforcement

# Configuration example: confirm TLS backend and disable HTTP/3 in curl CLI
curl -V | grep -E 'wolfSSL|HTTP3'
curl --http2 --pinnedpubkey sha256//BASE64HASH https://example.com/