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.
https://www.cisa.gov/news-events/ics-advisories/icsa-26-188-05
https://www.cisa.gov/news-events/ics-advisories/icsa-26-043-06
https://github.com/hamzamiladin/naptrace
https://hackerone.com/reports/3294999
https://euvd.enisa.europa.eu/vulnerability/EUVD-2025-29014
https://curl.se/docs/CVE-2025-9086.json
https://curl.se/docs/CVE-2025-9086.html
https://cert-portal.siemens.com/productcert/html/ssa-253495.html
https://cert-portal.siemens.com/productcert/html/ssa-089022.html