Aggregates CVE and security vulnerability intelligence across all cURL-related products, including CVSS, EPSS, publication dates, and vulnerability intelligence data.
Historical issues mainly involve vendor risk path handling, vendor risk input validation, and vendor risk ssrf and related problems; some flaws may lead to vendor impact file overwrite and vendor impact unexpected behavior.
| CVE | Summary | Source | Max CVSS | EPSS % | Published | Updated |
|---|---|---|---|---|---|---|
| CVE-2026-7168 | 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:` header field meant for `proxyA`, to `proxyB`. | 2499f714-1537-4658-8207-48ae4bb9eae9 | 5.3 | 0.05% | 2026-05-13 | 2026-05-14 |
| CVE-2026-7009 | When curl is told to use the Certificate Status Request TLS extension, often referred to as *OCSP stapling*, to verify that the server certificate is valid, it fails to detect OCSP problems and instead wrongly consider the response as fine. | 2499f714-1537-4658-8207-48ae4bb9eae9 | 5.3 | 0.01% | 2026-05-13 | 2026-05-14 |
| CVE-2026-6429 | 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. | 2499f714-1537-4658-8207-48ae4bb9eae9 | 5.3 | 0.02% | 2026-05-13 | 2026-05-14 |
| CVE-2026-6276 | Using libcurl, when a custom `Host:` header is first set for an HTTP request and a second request is subsequently done using the same *easy handle* but without the custom `Host:` header set, the second request would use stale information and pass on cookies meant for the first host in the second request. Leak them. | 2499f714-1537-4658-8207-48ae4bb9eae9 | 7.5 | 0.01% | 2026-05-13 | 2026-05-14 |
| CVE-2026-6253 | 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 credentials 4. while using the first proxy (using say `http://`), curl is asked to follow a redirect to a URL using another scheme (say `https://`), accessed using a second, different, proxy | 2499f714-1537-4658-8207-48ae4bb9eae9 | 5.9 | 0.02% | 2026-05-13 | 2026-05-14 |
| CVE-2026-5773 | libcurl might in some circumstances reuse the wrong connection for SMB(S) transfers. libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criteria must be met. Due to a logical error in the code, a network transfer operation that was requested by an application could wrongfully reuse an existing SMB connection to the same server that was using a different 'share' than the new subsequen | 2499f714-1537-4658-8207-48ae4bb9eae9 | 7.5 | 0.02% | 2026-05-13 | 2026-05-13 |
| CVE-2026-5545 | 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 connection to avoid overhead. When reusing a connection a range of criteria must be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the s | 2499f714-1537-4658-8207-48ae4bb9eae9 | 6.5 | 0.05% | 2026-05-13 | 2026-05-13 |
| CVE-2026-4873 | A vulnerability exists where a connection requiring TLS incorrectly reuses an existing unencrypted connection from the same connection pool. If an initial transfer is made in clear-text (via IMAP, SMTP, or POP3), a subsequent request to that same host bypasses the TLS requirement and instead transmit data unencrypted. | 2499f714-1537-4658-8207-48ae4bb9eae9 | 5.9 | 0.01% | 2026-05-13 | 2026-05-14 |
| CVE-2026-3805 | When doing a second SMB request to the same host again, curl would wrongly use a data pointer pointing into already freed memory. | 2499f714-1537-4658-8207-48ae4bb9eae9 | 7.5 | 0.04% | 2026-03-11 | 2026-03-12 |
| CVE-2026-3784 | curl would wrongly reuse an existing HTTP proxy connection doing CONNECT to a server, even if the new request uses different credentials for the HTTP proxy. The proper behavior is to create or use a separate connection. | 2499f714-1537-4658-8207-48ae4bb9eae9 | 6.5 | 0.02% | 2026-03-11 | 2026-06-02 |
| CVE-2026-3783 | 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 .netrc file, with either of the `machine` or `default` keywords, curl would pass on the bearer token set for the first host also to the second one. | 2499f714-1537-4658-8207-48ae4bb9eae9 | 5.3 | 0.02% | 2026-03-11 | 2026-03-12 |
| CVE-2026-1965 | 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 connection a range of criterion must first be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using diff | 2499f714-1537-4658-8207-48ae4bb9eae9 | 6.5 | 0.06% | 2026-03-11 | 2026-03-12 |
| CVE-2025-15224 | When doing SSH-based transfers using either SCP or SFTP, and asked to do public key authentication, curl would wrongly still ask and authenticate using a locally running SSH agent. | 2499f714-1537-4658-8207-48ae4bb9eae9 | 3.1 | 0.05% | 2026-01-08 | 2026-01-20 |
| CVE-2025-15079 | When doing SSH-based transfers using either SCP or SFTP, and setting the known_hosts file, libcurl could still mistakenly accept connecting to hosts *not present* in the specified file if they were added as recognized in the libssh *global* known_hosts file. | 2499f714-1537-4658-8207-48ae4bb9eae9 | 5.3 | 0.02% | 2026-01-08 | 2026-01-20 |
| CVE-2025-14819 | When doing TLS related transfers with reused easy or multi handles and altering the `CURLSSLOPT_NO_PARTIALCHAIN` option, libcurl could accidentally reuse a CA store cached in memory for which the partial chain option was reversed. Contrary to the user's wishes and expectations. This could make libcurl find and accept a trust chain that it otherwise would not. | 2499f714-1537-4658-8207-48ae4bb9eae9 | 5.3 | 0.06% | 2026-01-08 | 2026-01-20 |
| CVE-2025-14524 | When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer performs a cross-protocol redirect to a second URL that uses an IMAP, LDAP, POP3 or SMTP scheme, curl might wrongly pass on the bearer token to the new target host. | 2499f714-1537-4658-8207-48ae4bb9eae9 | 5.3 | 0.02% | 2026-01-08 | 2026-01-20 |
| CVE-2025-14017 | When doing multi-threaded LDAPS transfers (LDAP over TLS) with libcurl, changing TLS options in one thread would inadvertently change them globally and therefore possibly also affect other concurrently setup transfers. Disabling certificate verification for a specific transfer could unintentionally disable the feature for other threads as well. | 2499f714-1537-4658-8207-48ae4bb9eae9 | 6.3 | 0.01% | 2026-01-08 | 2026-01-27 |
| CVE-2025-13034 | When using `CURLOPT_PINNEDPUBLICKEY` option with libcurl or `--pinnedpubkey` with the curl tool,curl should check the public key of the server certificate to verify the peer. This check was skipped in a certain condition that would then make curl allow the connection without performing the proper check, thus not noticing a possible impostor. To skip this check, the connection had to be done with QUIC with ngtcp2 built to use GnuTLS and the user had to explicitly disable the standard certificate | 2499f714-1537-4658-8207-48ae4bb9eae9 | 5.9 | 0.01% | 2026-01-08 | 2026-01-20 |
| CVE-2025-10966 | curl's code for managing SSH connections when SFTP was done using the wolfSSH powered backend was flawed and missed host verification mechanisms. This prevents curl from detecting MITM attackers and more. | 2499f714-1537-4658-8207-48ae4bb9eae9 | 4.3 | 0.02% | 2025-11-07 | 2026-06-02 |
| CVE-2025-9086 | 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 potenti | 2499f714-1537-4658-8207-48ae4bb9eae9 | 7.5 | 0.27% | 2025-09-12 | 2026-06-02 |