curl EUVD-2026-72151

Exploitation requires two conditions to be met in sequence. First, curl must receive a Set-Cookie header that places a horizontal tab character (ASCII 9, not the standard space) immediately before the Secure keyword - no standards-compliant server emits this format by default, so the triggering server must be malicious, compromised, or severely misconfigured. Second, the same curl instance must subsequently make a plaintext HTTP request to the host and path covered by the cookie's scope; applications that enforce HTTPS exclusively are not exposed even if the Secure flag is dropped from the stored cookie. curl invocations that do not use a cookie jar (i.e., do not store and replay cookies across requests) are completely unaffected. PR:N in the CVSS reflects that no attacker authentication to the curl client is required; the attacker's leverage is server-side control over the Set-Cookie response.

The vendor-assigned CVSS 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N) reflects the theoretical maximum - unauthenticated network-accessible exploitation with high confidentiality impact. However, two sequential conditions must coincide for real exploitation: a server that sends a tab-delimited Secure attribute (not produced by any standards-compliant server implementation in its default configuration) and the curl client subsequently making a plaintext HTTP request to the same cookie-scoped host. If an application exclusively uses HTTPS, the dropped Secure flag causes no practical harm. EPSS at 0.22% (12th percentile) corroborates that the security community assesses widespread exploitation as unlikely. The CVE is absent from CISA KEV and no public exploit code was identified at time of analysis. The AC:L vendor score arguably overstates the ease of exploitation; an AC:H assessment better reflects the two-condition dependency. Despite the high CVSS score, this vulnerability is most relevant to applications that use curl's cookie jar against a potentially adversarial server and then downgrade to HTTP on the same host.

An attacker operating a server returns a HTTP response containing Set-Cookie: authtoken=SECRET;\tSecure; HttpOnly to a curl client making an HTTPS request; curl's parser ignores the Secure attribute due to the tab prefix and stores the cookie without the flag. On a subsequent plaintext HTTP request to the same host - for instance, when following a redirect or fetching a resource over HTTP - curl transmits the authtoken cookie in the clear, allowing a network-positioned observer or the malicious server itself to harvest the credential.