Curl vulnerabilities
We track 58 vulnerabilities in Curl products. 58 are rated high or critical, and none are known to be exploited. The most recent was published on October 20, 2026.
Latest Curl vulnerabilities
- 9.1 Critical severity
curl: Insufficiently Protected Credentials
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 fo
- 9.8 Critical severity
curl: Double Free
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.
- 9.1 Critical severity
curl: Insertion of Sensitive Information Into Sent Data
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-pa
- 8.1 High severity
curl: Improper Certificate Validation
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.
- 7.5 High severity
curl: Improper Certificate Validation
When a user invokes curl using a schemeless URL combined with `--proto-default` sftp (or scp), a disconnect occurs between the tool layer and libcurl. The tool layer incorrectly infers the URL scheme, which erroneously bypasses the initialization of critical S
- 9.8 Critical severity
curl: Authentication Bypass by Capture-replay
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 `Authoriz
- 7.5 High severity
curl: Allocation of Resources Without Limits or Throttling
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.
- 9.1 Critical severity
curl: Improper Certificate Validation
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 swit
- 7.5 High severity
curl: Loop with Unreachable Exit Condition
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
- 9.8 Critical severity
curl: Use After Free
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_
- 7.5 High severity
curl: Cleartext Transmission of Sensitive Information
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 me
- 7.5 High severity
curl: Server-Side Request Forgery
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 mus
- 7.5 High severity
curl: Out-of-bounds Read
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 sl
- 7.5 High severity
curl: Loop with Unreachable Exit Condition
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
- 7.3 High severity
curl: Buffer Copy without Checking Size of Input
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.
- 8.6 High severity
curl: Missing Release of Resource after Effective Lifetime
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 previ
- 9.8 Critical severity
curl: Out-of-bounds Write
This flaw makes curl overflow a heap based buffer in the SOCKS5 proxy handshake. When curl is asked to pass along the host name to the SOCKS5 proxy to allow that to resolve the address instead of it getting done by curl itself, the maximum length that host nam
- 7.5 High severity
curl: Allocation of Resources Without Limits or Throttling
When curl retrieves an HTTP response, it stores the incoming headers so that they can be accessed later via the libcurl headers API. However, curl did not have a limit in how many or how large headers it would accept in a response, allowing a malicious server