Description
1. A cookie is set using the `secure` keyword for `https://target` 2. curl is redirected to or otherwise made to speak with `http://target` (same hostname, but using clear text HTTP) using the same cookie set 3. The same cookie name is set - but with only a slash as path (`path="/"`). Since this site is not secure, the cookie *should* be ignored. 4. A bug in the path comparison logic makes curl read outside a heap buffer boundary The bug either causes a crash or it potentially makes the comparison come to the wrong conclusion and lets the clear-text site override the contents of the secure cookie, contrary to expectations and depending on the memory contents immediately following the single-byte allocation that holds the path. The presumed and correct behavior would be to plainly ignore the second set of the cookie since it was already set as secure on a secure host so overriding it on an insecure host should not be okay.
Affected products
haxx: curl; debian: debian linux
References7
- curl.se/docs/CVE-2025-9086.html PatchVendor Advisory
- curl.se/docs/CVE-2025-9086.json Vendor Advisory
- www.openwall.com/lists/oss-security/2025/09/10/1 Mailing ListPatchThird Party Advisory
- hackerone.com/reports/3294999 ExploitIssue TrackingThird Party Advisory
- lists.debian.org/debian-lts-announce/2026/01/msg00002.html Mailing ListThird Party Advisory
- cert-portal.siemens.com/productcert/html/ssa-089022.html
- cert-portal.siemens.com/productcert/html/ssa-253495.html
Metrics
- CVSS 3.1
-
7.5
HIGH
Score source: CNA
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H - EPSS — exploit probability
- 1% percentile: 74 · as of 8 November 2026
- CWE
- CWE-125
Could this be exploited in your environment?
A patch closes the known hole. A penetration test shows what an attacker can still reach — with proof.