CVE-2026-6276: 
cURL vulnerability analysis and mitigation

CVE-2026-6276 is a cookie disclosure vulnerability in libcurl titled "stale custom cookie host causes cookie leak." When an application sets a custom Host: header for an HTTP request and then makes a subsequent request using the same easy handle without the custom header, libcurl reuses stale host information and transmits cookies intended for the first host to the second host. Affected versions span libcurl 7.71.0 through 8.19.0 (inclusive); the curl command-line tool itself is not affected. The vulnerability was reported on April 14, 2026, and publicly disclosed on April 29, 2026, coordinated with the release of libcurl 8.20.0. It carries a CVSS v3.1 base score of 7.5 (High) per NVD, though the curl project rates its severity as Low due to significant mitigating factors (curl Advisory, Openwall OSS-Sec).

The root cause is classified as CWE-346 (Origin Validation Error) by the curl project, with the internal state variable data->state.aptr.cookiehost not being cleared between requests on the same easy handle when the custom Host: header is removed (curl Advisory, HackerOne Report). The bug was introduced in commit e15e51384a423be31318b3c9c7d612a1aae661fd and fixed in commit 3a19987a87f393d9394fe5acc7643f6c263c92db. Exploitation requires an application to: (1) use libcurl's easy handle API, (2) set a custom Host: header on a first request, and (3) reuse the same handle for a subsequent request to a different host without explicitly clearing the header. The impact is limited to plain HTTP transfers, as HTTPS would additionally require correct SNI configuration — a factor the curl project notes likely contributed to the flaw going undetected for so long (curl Advisory, Openwall OSS-Sec).

The primary consequence is confidentiality loss through unintended disclosure of session cookies or authentication tokens to an unintended host. An application reusing a libcurl easy handle across requests to different servers could inadvertently send sensitive cookies — including session identifiers or authentication credentials — to a second, potentially untrusted server. Because the flaw is limited to HTTP (not HTTPS with proper SNI), the practical scope is narrowed, but applications performing HTTP-based API calls or debugging workflows that reuse handles with custom Host: headers remain at risk of credential leakage and potential session hijacking (curl Advisory, Feedly).

A HackerOne disclosure report (report #3671818) exists but contains only a description of the vulnerability without runnable exploit code or step-by-step reproduction instructions; no functional proof-of-concept exploit is publicly available (HackerOne Report). There is no evidence of in-the-wild exploitation, no known threat actor attribution, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.008% (0.000080), reflecting very low probability of exploitation in the near term. Multiple Nessus detection plugins (IDs 310990, 311420, 312298, 313680, 315269) have been published to identify vulnerable systems (Feedly).

1. Identify a vulnerable application: Find an application that uses libcurl versions 7.71.0–8.19.0 via the easy handle API and performs HTTP (not HTTPS) requests with custom Host: headers, such as a debugging proxy or a multi-tenant HTTP client.
2. Trigger the first request: Cause the application to make an HTTP request with a custom Host: header set (e.g., Host: target-host.example.com) using a libcurl easy handle, which populates the stale data->state.aptr.cookiehost field.
3. Trigger the second request: Cause the application to reuse the same easy handle for a subsequent HTTP request to a different host without clearing the custom Host: header, so libcurl retains the stale cookie host context.
4. Intercept leaked cookies: Monitor or control the second destination server to capture the cookies that libcurl incorrectly forwards — these may include session tokens or authentication credentials intended for the first host.
5. Leverage captured credentials: Use the intercepted cookies to perform session hijacking or unauthorized access against the first host's services (curl Advisory, HackerOne Report).

• Network: Unexpected HTTP requests carrying Cookie: headers destined for a host that did not originally set those cookies; cookie values appearing in requests to unrelated endpoints or servers.
• Logs: Application HTTP access logs showing cookie headers on requests to hosts that should not receive them; libcurl debug output (if enabled via CURLOPT_VERBOSE) showing cookie transmission to unexpected destinations.
• Application Behavior: Unexplained authentication failures or session invalidation on the originating host, potentially indicating cookies were consumed or replayed elsewhere.

The primary remediation is to upgrade libcurl to version 8.20.0 or later, which contains the fix in commit 3a19987a87f393d9394fe5acc7643f6c263c92db (curl Advisory). If an immediate upgrade is not feasible, the curl project recommends applying the patch and rebuilding libcurl, or avoiding the use of custom Host: headers entirely. As an application-level workaround, developers should avoid reusing easy handles across requests to different hosts, or explicitly clear/reset the custom Host: header between requests. Downstream distributions including Red Hat (RHSA-2026:12916), Ubuntu (USN-8227-1), and SUSE have released updated packages (Red Hat Advisory, Ubuntu Advisory).

The vulnerability was disclosed by curl maintainer Daniel Stenberg via the oss-security mailing list on April 29, 2026, coordinated with the libcurl 8.20.0 release (Openwall OSS-Sec). The curl project rated the severity as "Low" due to the HTTPS/SNI mitigating factor, noting it is "probably a contributing factor why no one else found it before this" (curl Advisory). The vulnerability was reported by security researcher Muhamad Arga Reksapati via HackerOne. Downstream ecosystem adoption was broad, with patches quickly integrated into Red Hat, Ubuntu, SUSE, openSUSE, Alpine Linux, Puppet, Unraid, and HashiCorp Consul, reflecting the ubiquity of libcurl as a dependency.