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.
References
| Link | Resource |
|---|---|
| https://curl.se/docs/CVE-2025-9086.html | Vendor Advisory Patch |
| https://curl.se/docs/CVE-2025-9086.json | Vendor Advisory |
| https://hackerone.com/reports/3294999 | Exploit Issue Tracking Third Party Advisory |
| http://www.openwall.com/lists/oss-security/2025/09/10/1 | Mailing List Third Party Advisory Patch |
| https://lists.debian.org/debian-lts-announce/2026/01/msg00002.html | Mailing List Third Party Advisory |
Configurations
History
No history.
Information
Published : 2025-09-12 06:15
Updated : 2026-01-20 14:58
NVD link : CVE-2025-9086
Mitre link : CVE-2025-9086
CVE.ORG link : CVE-2025-9086
JSON object : View
Products Affected
debian
- debian_linux
haxx
- curl
CWE
CWE-125
Out-of-bounds Read