Search
Search Results (11 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-11856 | 2 Curl, Redhat | 2 Curl, Hummingbird | 2026-07-09 | 9.8 Critical |
| 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 meant for `hostA`, to `hostB`. | ||||
| CVE-2026-11564 | 2 Curl, Redhat | 2 Curl, Hummingbird | 2026-07-08 | 9.1 Critical |
| libcurl keeps previously used connections in a connection pool for subsequent transfers to reuse if one of them matches the setup. An easy handle that first uses default native CA trust can continue trusting the native platform store after the application switches that same handle to custom CA material for a later transfer. | ||||
| CVE-2026-8924 | 1 Curl | 1 Curl | 2026-07-07 | 9.1 Critical |
| 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-8925 | 1 Curl | 1 Curl | 2026-07-07 | 9.8 Critical |
| The curl logic that works with SASL authentication could end up cleaning up the GSASL context *twice* without clearing the pointer in between, making it `free()` the same pointer twice. | ||||
| CVE-2026-11352 | 1 Curl | 1 Curl | 2026-07-06 | 7.5 High |
| An issue in curl’s QUIC UDP receive function allows a malicious HTTP/3 server to trigger a remote denial of service against a curl or libcurl client. Because the helper function discards zero-length UDP datagrams before counting them toward the per-call packet budget, a connected QUIC peer can continuously stream empty datagrams to indefinitely stall the client. | ||||
| CVE-2026-11586 | 1 Curl | 1 Curl | 2026-07-06 | 7.5 High |
| By default, curl automatically responds to WebSocket PING frames. Because curl lacks an upper bound on memory allocation for unacknowledged frames, a malicious server can exhaust all available memory by flooding curl with rapid, sequential PING messages. | ||||
| CVE-2026-8927 | 1 Curl | 1 Curl | 2026-07-06 | 9.1 Critical |
| 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 transfer routed through `proxyB` erroneously leaks the `Proxy-Authorization:` header intended solely for `proxyA`. | ||||
| CVE-2026-9547 | 1 Curl | 1 Curl | 2026-07-06 | 7.4 High |
| 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 type already recorded for that host in the `known_hosts` file. Instead of rejecting the mismatch, the callback mechanism fails to properly enforce the restriction, allowing the connection to succeed without warning and risking a potential man-in-the-middle attack. | ||||
| CVE-2026-8926 | 1 Curl | 1 Curl | 2026-07-06 | 9.1 Critical |
| 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://user@example.com/`, curl could wrongly get and use the password for *another* user set in the `.netrc` file for that host if such a one exists and there is no match for the specified user. | ||||
| CVE-2026-8286 | 1 Curl | 1 Curl | 2026-07-06 | 8.1 High |
| 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-9545 | 1 Curl | 1 Curl | 2026-07-06 | 7.5 High |
| In this scenario, libcurl first uses a proper HTTP/3 server for the initial transfers, and when it makes a second transfer to the same site it has been replaced by the attacker's impostor machine - without a valid certificate. When libcurl returns to the hostname the second time with a cached SSL session (`CURLOPT_SSL_SESSIONID_CACHE` is not disabled) and early data enabled (the `CURLSSLOPT_EARLYDATA` bit is set in `CURLOPT_SSL_OPTIONS`), libcurl might send off the second request's bytes on that new connection *before* enforcing the certificate verification failure. Potentially leaking sensitive information. | ||||
Page 1 of 1.