CWE-125

OR
          *cpe:2.3:a:haxx:curl:*:*:*:*:*:*:*:* versions from (including) 8.13.0 up to (excluding) 8.16.0

OR
          *cpe:2.3:o:debian:debian_linux:11.0:*:*:*:*:*:*:*

CVE: http://www.openwall.com/lists/oss-security/2025/09/10/1 Types: Mailing List, Patch, Third Party Advisory

CVE: https://lists.debian.org/debian-lts-announce/2026/01/msg00002.html Types: Mailing List, Third Party Advisory

curl: https://curl.se/docs/CVE-2025-9086.html Types: Patch, Vendor Advisory

curl: https://curl.se/docs/CVE-2025-9086.json Types: Vendor Advisory

curl: https://hackerone.com/reports/3294999 Types: Exploit, Issue Tracking, Third Party Advisory

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 just a slash as path (`path='/'`).
   Since this site is not secure, the cookie *should* just 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.

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 just a slash as path (`path=\"/\",`).
   Since this site is not secure, the cookie *should* just 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://lists.debian.org/debian-lts-announce/2026/01/msg00002.html

http://www.openwall.com/lists/oss-security/2025/09/10/1

AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

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 just a slash as path (`path='/'`).
   Since this site is not secure, the cookie *should* just 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://curl.se/docs/CVE-2025-9086.html

https://curl.se/docs/CVE-2025-9086.json

https://hackerone.com/reports/3294999