curl vulnerabilities

When curl is asked to use HSTS, the expiry time for a subdomain might overwrite a parent domain's cache entry, making it end sooner or later than otherwise intended. This affects applications using HSTS and URLs with the insecure HTTP:// scheme.

When processing an HTTP redirect to a URL containing userinfo (a username:password component), curl might erroneously retain and re-transmit the original host's HTTP Negotiate authentication state. Consequently, a malicious server can trigger a redirect containing arbitrary userinfo to force curl to send a freshly minted Kerberos ticket to an untrusted third-party host, effectively bypassing the domain-scoping restrictions normally enforced by the absence of --location-trusted.

When built with wolfSSL, curl can successfully validate a pinned public key hash against a key the TLS peer does not possess. During the TLS handshake, wolfSSL validates the connection, but curl's subsequent re-parsing of the same certificate, tricked by a manipulated validity length field, extracts and matches a different embedded key, incorrectly authorizing the pinned public key.

When using ambient user credentials, an HTTP request directed to one origin may be dispatched over a connection previously authenticated via Negotiate for a different origin, leaving the request's intended credentials unused.

An HTTP proxy can trick libcurl into sending the origin's credentials (Basic password or a Negotiate/Kerberos ticket) to the proxy itself by answering the CONNECT tunnel request with 401 WWW-Authenticate instead of the expected 407 Proxy-Authenticate.

When using an ambient user in a first transfer doing Negotiate authentication and asked to follow redirects, curl could pass on its credential details to an unrelated second origin when asked to redirect there.

An ftp:// transfer configured with CURLUSESSL_NONE can reuse a pooled FTP control connection that a previous easy handle upgraded with STARTTLS and authenticated using a client certificate. The second handle performs neither a new TLS handshake nor a new FTP login, so the server continues to authorize it under the first handle's certificate identity.

When curl uses a .netrc file for credentials and a URL with a username (without password) is specified, curl may wrongly retrieve and use the password of another user from .netrc for that host if no match exists for the specified user.

A double-free vulnerability has been found in the curl library's SASL authentication handling. The GSASL context is cleaned up twice without clearing the pointer, causing free() to be called on the same memory region twice.

A flaw in curl's cookie parsing logic allows a malicious HTTP server to set "super cookies" that bypass the Public Suffix List check, enabling injection of cookies that curl scopes and sends to unrelated third-party domains.

CVE-2023-38545 is a vulnerability related to heap buffer overflow during the SOCKS5 proxy handshake in curl. The issue arises when curl passes a hostname that is too long to the proxy, leading to incorrect data copying.

A cleartext transmission of sensitive information vulnerability exists in curl <v7.88.0 that could cause HSTS functionality to fail when multiple URLs are requested serially. The HSTS mechanism is ignored by subsequent transfers on the same command line because the state is not properly carried on.

In curl before 7.84.0, during FTP transfers secured by krb5, message verification failures are handled incorrectly. This flaw makes it possible for a Man-In-The-Middle attack to go unnoticed and even allows it to inject data to the client.

When curl < 7.84.0 saves cookies, alt-svc and hsts data to local files, it makes the operation atomic by finalizing the operation with a rename from a temporary name to the final target file name. In that rename operation, it might accidentally *widen* the permissions for the target file, leaving the updated file accessible to more users than intended.

curl < 7.84.0 supports "chained" HTTP compression algorithms, meaning that a server response can be compressed multiple times and potentially with different algorithms. The number of acceptable "links" in this "decompression chain" was unbounded, allowing a malicious server to insert a virtually unlimited number of compression steps.

A malicious server can serve excessive amounts of `Set-Cookie:` headers in a HTTP response to curl and curl < 7.84.0 stores all of them. A sufficiently large amount of (big) cookies make subsequent HTTP requests to this, or other servers to which the cookies match, create requests that become larger than the threshold that curl uses internally to avoid sending crazy large requests (1048576 bytes) and instead returns an error.

A vulnerability in curl 7.83.0 related to insufficient protection of credentials. When following HTTP redirects to the same host but a different port, authentication or cookie header data may leak.

curl supports the `-t` command line option, known as `CURLOPT_TELNETOPTIONS` in libcurl. This rarely used option is used to send variable=content pairs to TELNET servers. Due to flaw in the option parser for sending `NEW_ENV` variables, libcurl could be made to pass on uninitialized data from a stack based buffer to the server. Therefore potentially revealing sensitive internal information to the server using a clear-text network protocol. This could happen because curl did not call and use sscanf() correctly when parsing the string provided by the application.

When curl is instructed to download content using the metalink feature, the contents is verified against a hash provided in the metalink XML file. The metalink XML file points out to the client how to get the same content from a set of different URLs, potentially hosted by different servers and the client can then download the file from one or several of them. In a serial or parallel manner. If one of the servers hosting the contents has been breached and the contents of the specific file on that server is replaced with a modified payload, curl should detect this when the hash of the file mismatches after a completed download. It should remove the contents and instead try getting the contents from another URL. This is not done, and instead such a hash mismatch is only mentioned in text and the potentially malicious content is kept in the file on disk.

curl versions 7.75.0 through 7.76.1 suffer from a use-after-free vulnerability resulting in already freed memory being used when a TLS 1.3 session ticket arrives over a connection. A malicious server can use this in rare unfortunate circumstances to potentially reach remote code execution in the client.

curl 7.7 through 7.76.1 suffers from information disclosure when the `-t` command line option (CURLOPT_TELNETOPTIONS in libcurl) is used to send variable=content pairs to TELNET servers. A parser flaw caused uninitialized stack data to be sent to the server.

curl 7.1.1 to and including 7.75.0 is vulnerable to an "Exposure of Private Personal Information to an Unauthorized Actor" by leaking credentials in the HTTP Referer: header. libcurl does not strip off user credentials from the URL when automatically populating the Referer: HTTP request header field in outgoing HTTP requests, and therefore risks leaking sensitive data to the server that is the target of the second HTTP request.

curl 7.41.0 through 7.73.0 is vulnerable to an improper check for certificate revocation due to insufficient verification of the OCSP response.

A malicious server can use the FTP PASV response to trick curl 7.73.0 and earlier into connecting back to a given IP address and port, potentially extracting information about otherwise private services.

curl versions 7.62.0 through 7.70.0 are vulnerable to an information disclosure vulnerability that can lead to a partial password being leaked over the network and to DNS servers.

When invoked with --remote-header-name (-J), curl fails to preserve its documented anti-clobbering protection if an intermediate 103 Early Hints response precedes the final HTTP response, or if an ETag header is processed before Content-Disposition under --etag-save. This flaw allows an HTTP(S) server to overwrite an existing local file specified in the Content-Disposition header despite the -J non-overwrite constraint.

When writing a long cookie name and value to a Netscape cookie jar, a remote HTTP server can make curl write a record that exceeds its line-length parsing limit. Consequently, any subsequent curl invocation reading from that same cookie jar using --cookie silently aborts parsing prematurely upon encountering the too long line, ignoring all subsequent valid cookies in the file.

Enabling CURLOPT_CRLF causes curl to advertise the raw input byte count in the IMAP APPEND {N} literal while transmitting line-ending expanded data. The server reads only N bytes for the payload, causing the remaining overflow bytes to be interpreted and executed as pipelined IMAP commands within the authenticated session.

An authenticated HTTPS origin can supply an HSTS max-age value that the parser accepts but time serialization later fails to process. On 64-bit systems, extreme max-age values compute an absolute expiry that exceeds calendar time structure bounds. During cache saves, the original HSTS file is truncated before writing a temporary replacement; when serialization fails, the temporary file is deleted, leaving an empty or partial cache, and the save error is silently ignored.

Importing an includeSubDomains parent HSTS entry before a longer-lived child entry silently drops the child. Consequently, when the parent expires, the child's valid HSTS policy is lost, causing curl to issue unencrypted HTTP requests rather than upgrading to HTTPS.

libcurl's connection cache match function never considers the automatic client certificate option, so a cached, already authenticated Schannel connection can be handed to a transfer redirected to a different origin, even though the code explicitly switched off the auto client cert option for that transfer.

When CURLOPT_INTERFACE (or --interface) is set with one of the documented prefixes (if!, host!, ifhost!), that binding is not part of the connection reuse key. A later transfer asking for a different source can silently reuse an existing connection and go out from the earlier transfer's source address.

When curl is built with GnuTLS, a malicious WebSocket server can make curl send memory past its send buffer. This is due to an out-of-bounds read when gnutls_record_send() returns a number of bytes sent greater than the number of bytes it was given to send, which GnuTLS does after a blocked send.

A remote HTTP server can set a cookie that curl accepts and writes to a Netscape cookie jar but cannot reload. On the next invocation using the same path for --cookie and --cookie-jar, curl fails before connecting, then the cleanup procedure replaces the jar with an empty file, deleting cookies for unrelated domains.

A flaw in the curl command line tool's logic makes it only set SSH host verification options when interacting directly using SFTP or SCP, and not as a result of following a redirect. As a result, SSH host verification may not be enabled after a redirect.

Setting `CURLOPT_AWS_SIGV4` to NULL does not disable SigV4 authentication, contrary to expectations and documentation. A subsequent transfer on the same handle still sends an `Authorization: AWS4-HMAC-SHA256` header to whatever URL is set next, leaking state information.

A vulnerability in curl during upload mishandles HTTP/2 RST_STREAM received from the server, leading to a use-after-free of a struct Curl_easy object.

A Set-Cookie header using a tab (ASCII 9) instead of a space (ASCII 32) immediately before the Secure attribute causes curl to store the cookie without its Secure flag. The cookie might then wrongfully be sent over plaintext HTTP on subsequent requests to the same host.

A vulnerability in curl causes the tool layer to skip initialization of critical SSH security options like CURLOPT_SSH_HOST_PUBLIC_KEY_SHA256 and CURLOPT_SSH_KNOWNHOSTS when using a schemeless URL with `--proto-default sftp` (or scp), while libcurl establishes the SFTP/SCP connection. This results in curl connecting to an unverified SSH remote host without error.

Curl lacks an upper bound on memory allocation for unacknowledged WebSocket PING frames, allowing a malicious server to exhaust all available memory by sending rapid sequential PING messages.

A vulnerability in curl's QUIC UDP receive function allows a malicious HTTP/3 server to trigger a remote denial of service (DoS) against a curl or libcurl client. The helper function discards zero-length UDP datagrams before counting them toward the per-call packet budget, enabling a connected QUIC peer to continuously stream empty datagrams and indefinitely stall the client.

curl might erroneously pass on credentials for a first proxy to a second proxy. This can happen when: 1. curl is set up to use 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 (e.g., http://), curl is asked to follow a redirect to a URL using another scheme (e.g., https://), accessed via a second, different proxy.

When an OAuth2 bearer token is used for an HTTP(S) transfer and that transfer redirects to a second URL, curl may leak the token to the second hostname under some circumstances. If the redirect target hostname has an entry in the .netrc file with the machine or default keyword, curl passes the bearer token set for the first host to the second one.

During SSH-based transfers using SCP or SFTP, when public key authentication is requested, curl incorrectly asks and authenticates using a locally running SSH agent.

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.

When using the CURLOPT_PINNEDPUBLICKEY option with libcurl or --pinnedpubkey with the curl tool, curl should check the public key of the server certificate. This check was skipped under a certain condition, allowing the connection without proper verification and failing to notice a possible impostor. The condition required a QUIC connection with ngtcp2 built with GnuTLS and explicit disabling of standard certificate verification.

A bug in curl's cookie path comparison logic makes curl read outside a heap buffer boundary. The scenario involves a cookie set with the secure keyword for https://target, a redirect to http://target (same hostname, clear text HTTP), and the same cookie name set with only a slash as path ("/"). The bug either causes a crash or makes the comparison come to the wrong conclusion, letting the clear-text site override the contents of the secure cookie.

curl's WebSocket code did not update the 32-bit mask pattern for each new outgoing frame as the specification requires. Instead it used a fixed mask that persisted throughout the entire connection. A predictable mask pattern allows a malicious server to induce traffic that an involved proxy may interpret as genuine HTTP traffic and poison its cache.

In curl, when a .netrc file is used for credentials and HTTP redirects are followed, the password used for the first host can be leaked to the followed-to host under certain circumstances. The flaw only manifests if the netrc file has a 'default' entry that omits both login and password.

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 and password.