CVE-2026-6276

What it actually does

This flaw is a libcurl state-management bug affecting applications that reuse the same libcurl easy handle across multiple HTTP requests. If an application first sends a request with a custom `Host:` header and then sends a later request on the same handle without that custom header, libcurl may retain stale host-related state and incorrectly attach cookies associated with the first host to the second request. The practical technical impact is unintended cookie disclosure across host boundaries, which may expose session cookies, API tokens stored as cookies, authentication state, or other sensitive cookie values to the wrong destination. Exploitability depends on application behavior: the application must use libcurl, enable or use cookies, set a custom `Host:` header, reuse the easy handle, and make a subsequent request to a different endpoint.

Why it matters to the business

Organizations using affected libcurl-based software may unintentionally leak authentication cookies or session data to unintended web services. If those cookies protect user sessions, internal APIs, management consoles, or partner integrations, the exposure could lead to account takeover, unauthorized access, privacy incidents, or regulatory reporting obligations. The risk is highest in applications that perform server-side HTTP requests to multiple domains, proxy requests, implement webhook/fetch functionality, scrape or crawl websites, or communicate with both internal and external services using reused libcurl handles. This issue is not listed in CISA KEV and has low EPSS at the time provided, but it has been public for 90 days, so remediation should be included in normal vulnerability management cycles and prioritized where cookies or privileged sessions are handled.

How an attack unfolds

An attacker generally cannot exploit this by simply connecting to a host running curl; they need to influence an application workflow that uses libcurl in the vulnerable pattern. A realistic attack starts by identifying or controlling an endpoint that the vulnerable application will contact, such as a webhook URL, redirect target, metadata fetch URL, URL preview service, import connector, or integration endpoint. The attacker then causes the application to perform a request sequence where libcurl first uses a custom `Host:` header for one host and later reuses the same easy handle for another request without that custom header. Because stale host state is retained, cookies intended for the first host may be sent with the second request. If the second request goes to attacker-controlled infrastructure, the attacker can capture the leaked `Cookie:` header from web server logs or packet capture and attempt to replay the session or extract sensitive values. Successful exploitation depends on cookie scope, whether cookies are authentication-bearing, TLS termination visibility, session binding controls, and whether the application reuses handles across trust boundaries.

How to fix it

Upgrade curl/libcurl to a vendor-supplied fixed release as soon as one is available for the affected platform. No exact fixed version was provided in the input, so use the operating system, container base image, language runtime, appliance, or software vendor advisory as the source of truth. Rebuild and redeploy applications that statically link libcurl, because updating the system package alone will not fix statically bundled copies. As interim mitigations, avoid reusing the same libcurl easy handle across different logical hosts or trust zones, call `curl_easy_reset()` before reusing a handle for another host, explicitly clear or replace custom headers between requests, avoid custom `Host:` headers unless strictly required, disable cookie handling where it is not needed, and clear cookies with `CURLOPT_COOKIELIST` where appropriate before cross-host reuse. Pay special attention to URL-fetching services, webhook processors, API gateways, proxies, crawlers, SSO integrations, and software that communicates with both internal and external HTTP services.

How to confirm the fix worked

Inventory systems and applications that use curl or libcurl, including OS packages, containers, appliances, embedded binaries, and statically linked applications. Confirm runtime versions with `curl --version`, package manager metadata, container image scans, SBOMs, and vendor advisories. Review application code for reuse of libcurl easy handles together with `CURLOPT_HTTPHEADER`, custom `Host:` headers, and cookie options such as `CURLOPT_COOKIEFILE`, `CURLOPT_COOKIEJAR`, `CURLOPT_COOKIE`, or cookie sharing. To validate remediation, run a regression test that performs one request with a custom `Host:` header and cookie state, then reuses the same easy handle for a second request to a different host without the custom header; the second request must not contain cookies belonging to the first host. For deployed software, enable temporary libcurl verbose/debug logging or controlled proxy inspection in a test environment and verify that `Cookie:` headers are only sent to intended domains.

Typical attack path

1. Identify an application or product that uses libcurl for outbound HTTP requests and supports user-influenced destinations, integrations, webhooks, redirects, crawlers, or URL-fetching features.
2. Determine whether the application uses cookies and reuses libcurl easy handles across requests to different hosts.
3. Trigger or wait for a request sequence where the first request uses a custom `Host:` header and stores or sends cookies for that host.
4. Cause a subsequent request on the same easy handle to be sent to an attacker-controlled or observable endpoint without the custom `Host:` header being set.
5. Capture unexpected `Cookie:` headers arriving at the attacker-controlled endpoint.
6. Replay or analyze leaked cookie values to attempt session hijacking, impersonation, or unauthorized access.

How to detect it

There is no universal network signature for exploitation because this is a client-side library behavior that manifests as legitimate-looking outbound HTTP requests containing incorrect cookies. Detection should focus on evidence that cookies were sent to destinations that should not receive them. Review outbound proxy logs, egress gateway logs, HTTP client debug logs, web server access logs for attacker-controlled or third-party endpoints, packet captures from controlled environments, and application logs that include request headers. Look for `Cookie:` headers on requests to domains that are unrelated to the cookie domain, especially after application actions involving webhooks, redirects, URL fetching, imports, crawlers, or integrations. In internal code or telemetry, search for combinations of libcurl handle reuse, `CURLOPT_HTTPHEADER`, custom `Host:` headers, and cookie options. If an exposure is suspected, treat affected cookies as compromised: invalidate sessions, rotate tokens stored in cookies, and review authentication logs for replay from unusual IP addresses, user agents, geographies, or service accounts.

What your security team should do

• Prioritize patching or vendor updates for internet-facing services, webhook handlers, URL preview/fetch features, proxies, crawlers, SSO components, and applications that send authenticated HTTP requests to multiple domains.
• Identify products and internally developed applications that use libcurl and determine whether they reuse easy handles across different hosts while enabling cookies or setting custom `Host:` headers.
• Update affected OS packages, container images, appliances, and third-party products; rebuild any statically linked applications or bundled libcurl distributions.
• Add secure coding guidance requiring libcurl handles and cookie jars to be isolated per destination trust boundary, or reset and clear state before reuse.
• Temporarily mitigate high-risk applications by disabling cookie handling for outbound requests that do not require cookies and blocking user-controlled outbound requests to untrusted destinations where feasible.
• Review outbound proxy, WAF, application, and destination server logs for unexpected `Cookie:` headers sent to external or unrelated domains.
• Create regression tests to ensure cookies are not sent across host boundaries after patching or code changes.