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.{
"priority_reason": "Curl developers have rated this as being low severity",
"availability": "No subscription required",
"binaries": [
{
"binary_version": "8.14.1-2ubuntu1.1",
"binary_name": "curl"
},
{
"binary_version": "8.14.1-2ubuntu1.1",
"binary_name": "libcurl3t64-gnutls"
},
{
"binary_version": "8.14.1-2ubuntu1.1",
"binary_name": "libcurl4-gnutls-dev"
},
{
"binary_version": "8.14.1-2ubuntu1.1",
"binary_name": "libcurl4-openssl-dev"
},
{
"binary_version": "8.14.1-2ubuntu1.1",
"binary_name": "libcurl4t64"
}
]
}