Haxx Curl vulnerabilities
134 known vulnerabilities affecting haxx/curl.
Total CVEs
134
CISA KEV
0
Public exploits
1
Exploited in wild
0
Severity breakdown
CRITICAL24HIGH41MEDIUM58LOW11
Vulnerabilities
Page 1 of 7
CVE-2026-3805HIGHCVSS 7.5≥ 8.13.0, < 8.19.02026-03-11
CVE-2026-3805 [HIGH] CWE-416 CVE-2026-3805: When doing a second SMB request to the same host again, curl would wrongly use
a data pointer pointi
When doing a second SMB request to the same host again, curl would wrongly use
a data pointer pointing into already freed memory.
nvd
CVE-2026-3784MEDIUMCVSS 6.5≥ 7.7, < 8.18.02026-03-11
CVE-2026-3784 [MEDIUM] CWE-305 CVE-2026-3784: curl would wrongly reuse an existing HTTP proxy connection doing CONNECT to a
server, even if the ne
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.
nvd
CVE-2026-3783MEDIUMCVSS 5.3≥ 7.33.0, < 8.19.02026-03-11
CVE-2026-3783 [MEDIUM] CWE-522 CVE-2026-3783: When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer
performs a redirect t
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
nvd
CVE-2026-1965MEDIUMCVSS 6.5≥ 7.10.6, < 8.19.02026-03-11
CVE-2026-1965 [MEDIUM] CWE-305 CVE-2026-1965: libcurl can in some circumstances reuse the wrong connection when asked to do
an Negotiate-authentic
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 c
nvd
CVE-2025-13034MEDIUMCVSS 5.9≥ 8.8.0, < 8.18.02026-01-08
CVE-2025-13034 [MEDIUM] CWE-295 CVE-2025-13034: When using `CURLOPT_PINNEDPUBLICKEY` option with libcurl or `--pinnedpubkey`
with the curl tool,curl
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 ski
nvd
CVE-2025-14524MEDIUMCVSS 5.3≥ 7.33.0, < 8.18.02026-01-08
CVE-2025-14524 [MEDIUM] CWE-601 CVE-2025-14524: When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer
performs a cross-prot
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.
nvd
CVE-2025-14017MEDIUMCVSS 6.3≥ 7.17.0, < 8.18.02026-01-08
CVE-2025-14017 [MEDIUM] CVE-2025-14017: When doing multi-threaded LDAPS transfers (LDAP over TLS) with libcurl,
changing TLS options in one
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.
nvd
CVE-2025-14819MEDIUMCVSS 5.3≥ 7.87.0, < 8.18.02026-01-08
CVE-2025-14819 [MEDIUM] CWE-295 CVE-2025-14819: When doing TLS related transfers with reused easy or multi handles and
altering the `CURLSSLOPT_NO_
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
nvd
CVE-2025-15079MEDIUMCVSS 5.3≥ 7.58.0, < 8.18.02026-01-08
CVE-2025-15079 [MEDIUM] CWE-297 CVE-2025-15079: When doing SSH-based transfers using either SCP or SFTP, and setting the
known_hosts file, libcurl c
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.
nvd
CVE-2025-15224LOWCVSS 3.1≥ 7.58.0, < 8.18.02026-01-08
CVE-2025-15224 [LOW] CWE-287 CVE-2025-15224: When doing SSH-based transfers using either SCP or SFTP, and asked to do
public key authentication,
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.
nvd
CVE-2025-10966MEDIUMCVSS 4.3≥ 7.69.0, < 8.17.02025-11-07
CVE-2025-10966 [MEDIUM] CVE-2025-10966: curl's code for managing SSH connections when SFTP was done using the wolfSSH
powered backend was fl
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.
nvd
CVE-2025-9086HIGHCVSS 7.5≥ 8.13.0, < 8.16.02025-09-12
CVE-2025-9086 [HIGH] CWE-125 CVE-2025-9086: 1. A cookie is set using the `secure` keyword for `https://target`
2. curl is redirected to or oth
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
nvd
CVE-2025-10148MEDIUMCVSS 5.3≥ 8.11.0, < 8.16.02025-09-12
CVE-2025-10148 [MEDIUM] CVE-2025-10148: curl's websocket code did not update the 32 bit mask pattern for each new
outgoing frame as the spe
curl's websocket code did not update the 32 bit mask pattern for each new
outgoing frame as the specification says. Instead it used a fixed mask that
persisted and was used throughout the entire connection.
A predictable mask pattern allows for a malicious server to induce traffic
between the two communicating parties that could be interpreted by an involv
nvd
CVE-2025-5399HIGHCVSS 7.5≥ 8.13.0, < 8.14.12025-06-07
CVE-2025-5399 [HIGH] CWE-835 CVE-2025-5399: Due to a mistake in libcurl's WebSocket code, a malicious server can send a
particularly crafted pac
Due to a mistake in libcurl's WebSocket code, a malicious server can send a
particularly crafted packet which makes libcurl get trapped in an endless
busy-loop.
There is no other way for the application to escape or exit this loop other
than killing the thread/process.
This might be used to DoS libcurl-using application.
nvd
CVE-2025-5025MEDIUMCVSS 4.8≥ 8.5.0, < 8.14.02025-05-28
CVE-2025-5025 [MEDIUM] CWE-295 CVE-2025-5025: libcurl supports *pinning* of the server certificate public key for HTTPS transfers. Due to an omiss
libcurl supports *pinning* of the server certificate public key for HTTPS transfers. Due to an omission, this check is not performed when connecting with QUIC for HTTP/3, when the TLS backend is wolfSSL. Documentation says the option works with wolfSSL, failing to specify that it does not for QUIC and HTTP/3. Since pinning makes the transfer succeed i
nvd
CVE-2025-4947MEDIUMCVSS 6.5≥ 8.8.0, < 8.14.02025-05-28
CVE-2025-4947 [MEDIUM] CWE-295 CVE-2025-4947: libcurl accidentally skips the certificate verification for QUIC connections when connecting to a ho
libcurl accidentally skips the certificate verification for QUIC connections when connecting to a host specified as an IP address in the URL. Therefore, it does not detect impostors or man-in-the-middle attacks.
nvd
CVE-2025-0725HIGHCVSS 7.3≥ 7.10.5, < 8.12.02025-02-05
CVE-2025-0725 [HIGH] CWE-120 CVE-2025-0725: When libcurl is asked to perform automatic gzip decompression of
content-encoded HTTP responses with
When libcurl is asked to perform automatic gzip decompression of
content-encoded HTTP responses with the `CURLOPT_ACCEPT_ENCODING` option,
**using zlib 1.2.0.3 or older**, an attacker-controlled integer overflow would
make libcurl perform a buffer overflow.
nvd
CVE-2025-0665HIGHCVSS 7.0v8.11.12025-02-05
CVE-2025-0665 [HIGH] CVE-2025-0665: libcurl would wrongly close the same eventfd file descriptor twice when taking
down a connection cha
libcurl would wrongly close the same eventfd file descriptor twice when taking
down a connection channel after having completed a threaded name resolve.
nvd
CVE-2025-0167LOWCVSS 3.4≥ 7.76.0, < 8.12.02025-02-05
CVE-2025-0167 [LOW] CVE-2025-0167: When asked to use a `.netrc` file for credentials **and** to follow HTTP
redirects, curl could leak
When asked to use a `.netrc` file for credentials **and** to follow HTTP
redirects, curl could leak the password used for the first host to the
followed-to host under certain circumstances.
This flaw only manifests itself if the netrc file has a `default` entry that
omits both login and password. A rare circumstance.
nvd
CVE-2024-11053LOWCVSS 3.4≥ 7.76.0, < 8.11.12024-12-11
CVE-2024-11053 [LOW] CVE-2024-11053: When asked to both use a `.netrc` file for credentials and to follow HTTP
redirects, curl could leak
When asked to both use a `.netrc` file for credentials and to follow HTTP
redirects, curl could leak the password used for the first host to the
followed-to host under certain circumstances.
This flaw only manifests itself if the netrc file has an entry that matches
the redirect target hostname but the entry either omits just the password or
omits both login
nvd
1 / 7Next →