No QUIC certificate pinning with wolfSSL

Vulnerability

libcurl versions 8.5.0 through 8.13.0, when built with the wolfSSL TLS backend, do not perform the configured server certificate public key pinning (CURLOPT_PINNEDPUBLICKEY) during QUIC connections for HTTP/3. The option correctly works for TCP-based TLS (HTTP/1 and HTTP/2). The documented support for wolfSSL does not specify this limitation. The flaw was introduced in commit 5f78cf503c786a1d48d1352 [1].

Exploitation

An attacker with network position to perform a man-in-the-middle attack can present a rogue QUIC server certificate. Since the pinning check is silently skipped, the transfer proceeds normally without alerting the user or application, as long as the server certificate otherwise validates. No special authentication or user interaction is required beyond initiating an HTTPS/3 transfer with a pinned public key [1].

Impact

Successful exploitation results in the client establishing a TLS session with an untrusted server while the application or user believes the certificate pin is protecting them. This allows the attacker to intercept, modify, or inject data in the HTTPS connection, leading to information disclosure, data integrity compromise, and potential further application-level attacks. The severity is rated Medium (CVSS not specified in the references) [1].

Mitigation

Upgrade to curl 8.14.0, which includes the fix in commit e1f65937a96a451292e92313396. Users unable to upgrade can avoid using HTTP/3 or certificate pinning as a workaround. Versions prior to 8.5.0 are not affected because HTTP/3 was experimental and not expected to work fully, but they are also not corrected [1].