CVE-2026-9545: 
cURL vulnerability analysis and mitigation

CVE-2026-9545 is an information disclosure vulnerability in libcurl affecting HTTP/3 connections, officially titled "exposing HTTP/3 early data." It affects curl versions 8.11.0 through 8.20.0 (inclusive) and was reported to the curl project on May 19, 2026, with coordinated disclosure and the release of curl 8.21.0 on June 24, 2026 (curl Advisory). The vulnerability was discovered by Eunsoo Kim of the Autonomous Code Security team at Microsoft and patched by Stefan Eissing (curl Advisory). It carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory), though the curl project itself rates the severity as Low (curl Advisory).

The root cause is improper certificate validation (CWE-295) combined with exposure of sensitive information (CWE-200) in libcurl's HTTP/3 implementation using the ngtcp2 + nghttp3 backend (curl Advisory, curl JSON). When libcurl reconnects to a hostname with a cached SSL session (CURLOPT_SSL_SESSIONID_CACHE enabled by default) and TLS early data enabled (CURLSSLOPT_EARLYDATA bit set in CURLOPT_SSL_OPTIONS), it may transmit the second request's data bytes over the new connection before completing certificate verification — a race condition between early data transmission and certificate enforcement (curl Advisory). This is specific to HTTPS URLs over HTTP/3 and also affects the curl command-line tool, not just the library. The vulnerable code was introduced at commit 962097b8dd44ed5b9e7984bc1cdffdbdd566857f and fixed at 7b9613fa9b1a5e04301a3920eef58e8138dad05e (curl JSON). A detailed PoC bash script demonstrating the issue is available via the HackerOne report (HackerOne).

Successful exploitation allows an unauthenticated network attacker performing a man-in-the-middle attack to capture sensitive HTTP/3 request data — such as Authorization headers, session tokens, or POST body content — that libcurl transmits before detecting the invalid certificate (curl Advisory, Feedly). The impact is limited to confidentiality; integrity and availability are not affected. The scope is constrained to scenarios where both SSL session caching and TLS early data are simultaneously active on HTTP/3 connections, reducing the practical attack surface.

1. Reconnaissance: Identify applications using libcurl 8.11.0–8.20.0 with HTTP/3 enabled (ngtcp2 + nghttp3 backend), SSL session caching active (default), and TLS early data enabled via CURLSSLOPT_EARLYDATA.
2. Position for MitM: Gain a network position to intercept or redirect traffic from the target client to the legitimate HTTP/3 server — for example, via ARP spoofing, DNS poisoning, or BGP hijacking.
3. Allow initial legitimate connection: Let libcurl complete its first HTTP/3 connection to the real server, establishing and caching a valid TLS session ticket.
4. Replace server with impostor: Substitute the legitimate server with an attacker-controlled machine that presents an invalid or self-signed certificate for the same hostname.
5. Trigger second request: Cause the libcurl-based application to make a second request to the same hostname (e.g., a follow-up API call or redirect).
6. Capture early data: Because libcurl uses the cached SSL session and sends early data before certificate verification completes, the second request's bytes (including sensitive headers like Authorization) are transmitted to the impostor server and captured by the attacker (curl Advisory, HackerOne).

• Network: Unexpected HTTP/3 (QUIC/UDP port 443) connections from client systems to unfamiliar or newly observed IP addresses for known hostnames; TLS session resumption attempts followed by certificate errors in network logs.
• Logs: Application or libcurl debug logs showing certificate verification failures (SSL certificate problem) on HTTP/3 connections immediately after a successful session; curl verbose output (-v) indicating early data was sent (* Using HTTP/3) before a cert error.
• Process/Application: Applications making repeated HTTP/3 requests to the same host with CURLSSLOPT_EARLYDATA set, where the second request results in a TLS handshake failure — particularly if sensitive data (auth tokens, credentials) was included in that request.

The primary remediation is to upgrade curl and libcurl to version 8.21.0 or later, which contains the fix at commit 7b9613fa9b1a5e04301a3920eef58e8138dad05e (curl Advisory). If immediate upgrade is not possible, two configuration-based workarounds are available: disable SSL session caching by setting CURLOPT_SSL_SESSIONID_CACHE to 0, or disable TLS early data by unsetting the CURLSSLOPT_EARLYDATA bit in CURLOPT_SSL_OPTIONS (curl Advisory, Feedly). Organizations using Red Hat products should monitor the Red Hat Bugzilla tracker for package updates (Red Hat Bugzilla).

The curl project's lead developer Daniel Stenberg announced the release of curl 8.21.0 — which patched 18 security flaws including this one — on his blog (Daniel Haxx Blog). Several security news outlets covered the release, with some highlighting a separate "25-year-old vulnerability" also patched in the same release, drawing broader attention to the curl 8.21.0 security update (CyberSecurityNews, CyberPress). Community discussion was moderate, with Linux distribution maintainers (Ubuntu, openSUSE, Alpine) promptly issuing updated packages (Linux Compatible).