CVE-2026-9546: 
cURL vulnerability analysis and mitigation

CVE-2026-9546 is an information disclosure vulnerability in libcurl, described as "sending old referer," in which the HTTP Referer: header persists even when explicitly cleared via CURLOPT_REFERER set to NULL. The bug was introduced in curl 8.18.0 and affects versions 8.18.0 through 8.20.0; curl 8.21.0 (released June 24, 2026) contains the fix. The curl command-line tool is not affected — only applications using libcurl directly are impacted. It carries a CVSS v3.1 base score of 7.5 (High) per NVD/GitHub Advisory, though the curl project itself rates severity as Low (curl Advisory, GitHub Advisory).

The root cause is classified as CWE-201 (Insertion of Sensitive Information Into Sent Data) by NVD, and CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) by the curl project itself (curl Advisory). The flaw was introduced by commit 2cb868242dc2ac9cd52ee64987ef51d5964a56f9 and fixed in 862e8a74a84478d82973471b4f49dc2746c1780e. When an application reuses a curl easy handle across multiple requests and sets CURLOPT_REFERER to NULL between requests to suppress the header, libcurl fails to clear its internal referrer state — causing the previously set referrer string to be transmitted in subsequent requests to potentially different, unintended servers. A public proof-of-concept consisting of a C client program and a Python HTTP server that reproduces the stale referrer leak is available via HackerOne (HackerOne PoC).

The primary impact is a confidentiality breach: sensitive information embedded in a Referer: header (such as URLs containing tokens, session identifiers, or other private data) may be inadvertently disclosed to unintended third-party servers when libcurl reuses a handle across requests. There is no integrity or availability impact. The scope is limited to applications that use libcurl programmatically, set CURLOPT_REFERER to a sensitive value, then attempt to clear it with NULL before making subsequent requests to different destinations (curl Advisory, GitHub Advisory).

1. Identify a vulnerable target: Find an application that uses libcurl versions 8.18.0–8.20.0, reuses easy handles across HTTP requests, and sets CURLOPT_REFERER to a sensitive value (e.g., a URL containing a token or session ID).
2. Set up a controlled server: Deploy an HTTP server (e.g., a simple Python server) capable of logging all incoming request headers, including Referer:.
3. Trigger the first request: Cause the target application to make an HTTP request with a sensitive Referer: header set via CURLOPT_REFERER to a first URL.
4. Trigger the NULL clear: Observe or confirm that the application sets CURLOPT_REFERER to NULL on the reused handle, intending to suppress the header for subsequent requests.
5. Trigger the second request: Cause the application to make a subsequent HTTP request to a second URL (potentially attacker-controlled or a third-party server).
6. Capture the leaked header: The stale referrer string from step 3 is erroneously included in the second request's Referer: header, exposing the sensitive value to the second server (HackerOne PoC, curl Advisory).

• Network: HTTP requests from a libcurl-based application to third-party or unexpected servers containing a Referer: header with values that should have been suppressed (e.g., internal URLs, URLs with tokens or session parameters).
• Logs: Server-side access logs on receiving servers showing unexpected Referer: header values in requests where no referrer was intended; application logs showing libcurl requests to multiple distinct hosts with the same referrer value persisting across calls.
• Application Behavior: Any libcurl-based application using versions 8.18.0–8.20.0 that sets CURLOPT_REFERER to NULL between requests on a reused handle should be considered potentially affected.

Upgrade libcurl to version 8.21.0 or later, which contains the fix (commit 862e8a74a84478d82973471b4f49dc2746c1780e) (curl Advisory). If an immediate upgrade is not possible, the curl project recommends avoiding use of CURLOPT_REFERER entirely as a workaround, or applying the patch manually and rebuilding. Application developers should also audit code that reuses curl easy handles to verify referrer handling behavior, and review server logs to determine whether sensitive referrer data may have been leaked to unintended destinations (GitHub Advisory, Red Hat Bugzilla).

The curl 8.21.0 release, which patched 18 security vulnerabilities including CVE-2026-9546, received notable media coverage. Several outlets highlighted a "25-year-old vulnerability" in curl (referring to a separate issue in the same release) alongside this flaw, generating broad community interest. Daniel Stenberg, curl's lead developer, published a release blog post and served as the remediation developer for this specific CVE. Security news outlets including CyberPress, CyberSecurityNews, and VPNcentral covered the release (Daniel Stenberg Blog).