Описание
ELSA-2026-1350: curl security update (MODERATE)
[7.76.1-35.el9_7.3]
- http: fix crash in rate-limited upload (RHEL-129493)
[7.76.1-35.el9_7.2]
- openssl: respect system crypto policy for TLS max version (RHEL-128921)
[7.76.1-35.el9_7.1]
- rebuild for rhel-9.7.0 z-stream (RHEL-121659)
[7.76.1-35]
- cookie: don't treat the leading slash as trailing (CVE-2025-9086) Resolves: RHEL-121659
Обновленные пакеты
Oracle Linux 9
Oracle Linux aarch64
curl
7.76.1-35.el9_7.3
curl-minimal
7.76.1-35.el9_7.3
libcurl
7.76.1-35.el9_7.3
libcurl-devel
7.76.1-35.el9_7.3
libcurl-minimal
7.76.1-35.el9_7.3
Oracle Linux x86_64
curl
7.76.1-35.el9_7.3
curl-minimal
7.76.1-35.el9_7.3
libcurl
7.76.1-35.el9_7.3
libcurl-devel
7.76.1-35.el9_7.3
libcurl-minimal
7.76.1-35.el9_7.3
Связанные CVE
Связанные уязвимости
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.
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 ...