rpm package
almalinux/libcurl-minimal
pkg:rpm/almalinux/libcurl-minimal
Vulnerabilities (43)
| CVE | Sev | CVSS | KEV | Affected versions | Fixed in | Published | Description |
|---|---|---|---|---|---|---|---|
| CVE-2026-9547 | Hig | 7.4 | < 7.76.1-40.el9_8.5 | 7.76.1-40.el9_8.5 | Jul 3, 2026 | When a libcurl-based application performs transfers via `SCP://` or `SFTP://` and utilizes the `CURLOPT_SSH_KEYFUNCTION` callback, it may silently accept an untrusted server. This vulnerability occurs when a server presents a host key type that does not match the specific key typ | |
| CVE-2026-9079 | Cri | 9.8 | < 8.12.1-4.el10_2.6 | 8.12.1-4.el10_2.6 | Jul 3, 2026 | libcurl had a flaw that when instructed to clear proxy authentication credentials which made it not do so, leaving the old credentials around to get used for subsequent transfers that should not know nor use them. | |
| CVE-2026-8932 | Hig | 7.5 | < 8.12.1-4.el10_2.6 | 8.12.1-4.el10_2.6 | Jul 3, 2026 | libcurl would reuse a previously created connection even when some mTLS config related option had been changed that should have prohibited reuse. libcurl keeps previously used connections in a connection pool for subsequent transfers to reuse if one of them matches the setup. Ho | |
| CVE-2026-8927 | Cri | 9.1 | < 8.12.1-4.el10_2.4 | 8.12.1-4.el10_2.4 | Jul 3, 2026 | When reusing a libcurl handle for sequential transfers driven by environment-variable proxy configuration, libcurl fails to clear the proxy authentication state between requests. Specifically, if the initial transfer authenticates against `proxyA` using Digest auth, a subsequent | |
| CVE-2026-8926 | Cri | 9.1 | < 8.12.1-4.el10_2.6 | 8.12.1-4.el10_2.6 | Jul 3, 2026 | When asking curl to use a `.netrc` file to find credentials and at the same time specifying a URL with a username (without a password), like `https://[email protected]/`, curl could wrongly get and use the password for *another* user set in the `.netrc` file for that host if such | |
| CVE-2026-8924 | Cri | 9.1 | < 8.12.1-4.el10_2.6 | 8.12.1-4.el10_2.6 | Jul 3, 2026 | A flaw in curl’s cookie parsing logic allows a malicious HTTP server to set "super cookies" that bypass the Public Suffix List check. This enables an attacker-controlled origin to inject cookies that curl subsequently scopes and transmits to unrelated third-party domains. | |
| CVE-2026-8458 | Med | 6.5 | < 8.12.1-4.el10_2.6 | 8.12.1-4.el10_2.6 | Jul 3, 2026 | libcurl might in some circumstances reuse the wrong connection when asked to do Negotiate-authenticated ones, even when they are set to use different "services". libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid o | |
| CVE-2026-8286 | Hig | 8.1 | < 7.76.1-40.el9_8.5 | 7.76.1-40.el9_8.5 | Jul 3, 2026 | A vulnerability exists where a new transfer that uses STARTTLS to upgrade the connection might reuse an existing live connection even though the TLS configuration mismatches so it should not. | |
| CVE-2026-11856 | Cri | 9.8 | < 8.12.1-4.el10_2.6 | 8.12.1-4.el10_2.6 | Jul 3, 2026 | Successfully using libcurl to do a transfer to a specific HTTP origin (`hostA`) with **Digest** authentication and then changing the origin to a different one (`hostB`) for a second transfer, reusing the same handle, makes libcurl wrongly pass on the `Authorization:` header field | |
| CVE-2026-10536 | Cri | 9.8 | < 8.12.1-4.el10_2.7 | 8.12.1-4.el10_2.7 | Jul 3, 2026 | A use-after-free vulnerability exists in libcurl when an application configures an HTTP/2 stream-dependency tree via `CURLOPT_STREAM_DEPENDS` or `CURLOPT_STREAM_DEPENDS_E`, subsequently invokes `curl_easy_reset()`, and finally terminates the handle with `curl_easy_cleanup()`. Dur | |
| CVE-2026-7168 | Med | 5.3 | < 8.12.1-4.el10_2.7 | 8.12.1-4.el10_2.7 | May 13, 2026 | Successfully using libcurl to do a transfer over a specific HTTP proxy (`proxyA`) with **Digest** authentication and then changing the proxy host to a second one (`proxyB`) for a second transfer, reusing the same handle, makes libcurl wrongly pass on the `Proxy-Authorization:` he | |
| CVE-2026-6429 | Med | 5.3 | < 8.12.1-4.el10_2.7 | 8.12.1-4.el10_2.7 | May 13, 2026 | When asked to both use a `.netrc` file for credentials and to follow HTTP redirects, libcurl could leak the password used for the first host to the followed-to host under certain circumstances. | |
| CVE-2026-6253 | Med | 5.9 | < 8.12.1-4.el10_2.7 | 8.12.1-4.el10_2.7 | May 13, 2026 | curl might erroneously pass on credentials for a first proxy to a second proxy. This can happen when the following conditions are true: 1. curl is setup to use specific different proxies for different URL schemes 2. the first proxy needs credentials 3. the second proxy uses no | |
| CVE-2026-5545 | Med | 6.5 | < 8.12.1-4.el10_2.7 | 8.12.1-4.el10_2.7 | May 13, 2026 | libcurl might in some circumstances reuse the wrong connection when asked to do an authenticated HTTP(S) request after a Negotiate-authenticated one, when both use the same host. libcurl features a pool of recent connections so that subsequent requests can reuse an existing conn | |
| CVE-2026-3783 | Med | 5.3 | < 7.76.1-40.el9_8.5 | 7.76.1-40.el9_8.5 | Mar 11, 2026 | When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer performs a redirect to a second URL, curl could leak that token to the second hostname under some circumstances. If the hostname that the first request is redirected to has information in the used .ne | |
| CVE-2026-1965 | Med | 6.5 | < 7.76.1-40.el9_8.5 | 7.76.1-40.el9_8.5 | Mar 11, 2026 | libcurl can in some circumstances reuse the wrong connection when asked to do an Negotiate-authenticated HTTP or HTTPS request. libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connectio | |
| CVE-2025-9086 | Hig | 7.5 | < 7.61.1-34.el8_10.9 | 7.61.1-34.el8_10.9 | Sep 12, 2025 | 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 (`pat | |
| CVE-2024-2398 | Hig | 8.6 | < 7.76.1-29.el9_4.1 | 7.76.1-29.el9_4.1 | Mar 27, 2024 | When an application tells libcurl it wants to allow HTTP/2 server push, and the amount of received headers for the push surpasses the maximum allowed limit (1000), libcurl aborts the server push. When aborting, libcurl inadvertently does not free all the previously allocated head | |
| CVE-2023-46218 | Med | 6.5 | < 7.76.1-26.el9_3.3 | 7.76.1-26.el9_3.3 | Dec 7, 2023 | This flaw allows a malicious HTTP server to set "super cookies" in curl that are then passed back to more origins than what is otherwise allowed or possible. This allows a site to set cookies that then would get sent to different and unrelated sites and domains. It could do this | |
| CVE-2023-38546 | Low | 3.7 | < 7.76.1-23.el9_2.4 | 7.76.1-23.el9_2.4 | Oct 18, 2023 | This flaw allows an attacker to insert cookies at will into a running program using libcurl, if the specific series of conditions are met. libcurl performs transfers. In its API, an application creates "easy handles" that are the individual handles for single transfers. libcurl |
- affected < 7.76.1-40.el9_8.5fixed 7.76.1-40.el9_8.5
When a libcurl-based application performs transfers via `SCP://` or `SFTP://` and utilizes the `CURLOPT_SSH_KEYFUNCTION` callback, it may silently accept an untrusted server. This vulnerability occurs when a server presents a host key type that does not match the specific key typ
- affected < 8.12.1-4.el10_2.6fixed 8.12.1-4.el10_2.6
libcurl had a flaw that when instructed to clear proxy authentication credentials which made it not do so, leaving the old credentials around to get used for subsequent transfers that should not know nor use them.
- affected < 8.12.1-4.el10_2.6fixed 8.12.1-4.el10_2.6
libcurl would reuse a previously created connection even when some mTLS config related option had been changed that should have prohibited reuse. libcurl keeps previously used connections in a connection pool for subsequent transfers to reuse if one of them matches the setup. Ho
- affected < 8.12.1-4.el10_2.4fixed 8.12.1-4.el10_2.4
When reusing a libcurl handle for sequential transfers driven by environment-variable proxy configuration, libcurl fails to clear the proxy authentication state between requests. Specifically, if the initial transfer authenticates against `proxyA` using Digest auth, a subsequent
- affected < 8.12.1-4.el10_2.6fixed 8.12.1-4.el10_2.6
When asking curl to use a `.netrc` file to find credentials and at the same time specifying a URL with a username (without a password), like `https://[email protected]/`, curl could wrongly get and use the password for *another* user set in the `.netrc` file for that host if such
- affected < 8.12.1-4.el10_2.6fixed 8.12.1-4.el10_2.6
A flaw in curl’s cookie parsing logic allows a malicious HTTP server to set "super cookies" that bypass the Public Suffix List check. This enables an attacker-controlled origin to inject cookies that curl subsequently scopes and transmits to unrelated third-party domains.
- affected < 8.12.1-4.el10_2.6fixed 8.12.1-4.el10_2.6
libcurl might in some circumstances reuse the wrong connection when asked to do Negotiate-authenticated ones, even when they are set to use different "services". libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid o
- affected < 7.76.1-40.el9_8.5fixed 7.76.1-40.el9_8.5
A vulnerability exists where a new transfer that uses STARTTLS to upgrade the connection might reuse an existing live connection even though the TLS configuration mismatches so it should not.
- affected < 8.12.1-4.el10_2.6fixed 8.12.1-4.el10_2.6
Successfully using libcurl to do a transfer to a specific HTTP origin (`hostA`) with **Digest** authentication and then changing the origin to a different one (`hostB`) for a second transfer, reusing the same handle, makes libcurl wrongly pass on the `Authorization:` header field
- affected < 8.12.1-4.el10_2.7fixed 8.12.1-4.el10_2.7
A use-after-free vulnerability exists in libcurl when an application configures an HTTP/2 stream-dependency tree via `CURLOPT_STREAM_DEPENDS` or `CURLOPT_STREAM_DEPENDS_E`, subsequently invokes `curl_easy_reset()`, and finally terminates the handle with `curl_easy_cleanup()`. Dur
- affected < 8.12.1-4.el10_2.7fixed 8.12.1-4.el10_2.7
Successfully using libcurl to do a transfer over a specific HTTP proxy (`proxyA`) with **Digest** authentication and then changing the proxy host to a second one (`proxyB`) for a second transfer, reusing the same handle, makes libcurl wrongly pass on the `Proxy-Authorization:` he
- affected < 8.12.1-4.el10_2.7fixed 8.12.1-4.el10_2.7
When asked to both use a `.netrc` file for credentials and to follow HTTP redirects, libcurl could leak the password used for the first host to the followed-to host under certain circumstances.
- affected < 8.12.1-4.el10_2.7fixed 8.12.1-4.el10_2.7
curl might erroneously pass on credentials for a first proxy to a second proxy. This can happen when the following conditions are true: 1. curl is setup to use specific different proxies for different URL schemes 2. the first proxy needs credentials 3. the second proxy uses no
- affected < 8.12.1-4.el10_2.7fixed 8.12.1-4.el10_2.7
libcurl might in some circumstances reuse the wrong connection when asked to do an authenticated HTTP(S) request after a Negotiate-authenticated one, when both use the same host. libcurl features a pool of recent connections so that subsequent requests can reuse an existing conn
- affected < 7.76.1-40.el9_8.5fixed 7.76.1-40.el9_8.5
When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer performs a redirect to a second URL, curl could leak that token to the second hostname under some circumstances. If the hostname that the first request is redirected to has information in the used .ne
- affected < 7.76.1-40.el9_8.5fixed 7.76.1-40.el9_8.5
libcurl can in some circumstances reuse the wrong connection when asked to do an Negotiate-authenticated HTTP or HTTPS request. libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connectio
- affected < 7.61.1-34.el8_10.9fixed 7.61.1-34.el8_10.9
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 (`pat
- affected < 7.76.1-29.el9_4.1fixed 7.76.1-29.el9_4.1
When an application tells libcurl it wants to allow HTTP/2 server push, and the amount of received headers for the push surpasses the maximum allowed limit (1000), libcurl aborts the server push. When aborting, libcurl inadvertently does not free all the previously allocated head
- affected < 7.76.1-26.el9_3.3fixed 7.76.1-26.el9_3.3
This flaw allows a malicious HTTP server to set "super cookies" in curl that are then passed back to more origins than what is otherwise allowed or possible. This allows a site to set cookies that then would get sent to different and unrelated sites and domains. It could do this
- affected < 7.76.1-23.el9_2.4fixed 7.76.1-23.el9_2.4
This flaw allows an attacker to insert cookies at will into a running program using libcurl, if the specific series of conditions are met. libcurl performs transfers. In its API, an application creates "easy handles" that are the individual handles for single transfers. libcurl
Page 1 of 3