eventfd double close

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.

A flaw in libcurl makes it wrongly reuse an HTTP connection setup for a given hostname using Negotiate authentication, when the initial request is done using empty credentials. This can make user B's request get sent over user A's previously authenticated connection.

An ftp:// transfer configured with CURLUSESSLNONE 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.

A flaw in libcurl's handling of HTTP/2 Server Push streams, when the parent handle is set to share connections with other handles, can lead to use-after-free in the cleanup process.

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.

When libpsl support is enabled, libcurl fails to enforce the Public Suffix List boundary check when processing a Set-Cookie header where the Domain attribute explicitly matches an origin host that is itself a public suffix (e.g., Domain=co.uk set by co.uk).

Instead of coercing it into a strict host-only cookie, libcurl saves the cookie with wildcard domain scope (.co.uk). Consequently, the cookie is inappropriately included in subsequent outbound requests or HTTP redirects to arbitrary sibling subdomains under the same public suffix (e.g., attacker.co.uk).

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.

Last updated 10 July 2026

stale custom cookie host causes cookie leak

auto client cert connection reuse mixup

libcurl would reuse a previously created connection even when some mTLS config related option had been changed that should have prohibited reuse.

libcurl keeps previously used connections in a connection pool for subsequent transfers to reuse if one of them matches the setup. However, some TLS settings related to client certificates were left out from the configuration match checks, making them match too easily. In particular options related to the private key.

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.

A vulnerability in libcurl caused the HTTP Referer: header to persist even when explicitly cleared. While the documentation states that passing NULL to CURLOPTREFERER suppresses the header, the option failed to clear the internal state. As a result, the previous referrer string was erroneously reused and sent in subsequent requests, potentially leaking sensitive information to unintended servers.

Due to use of a dangling pointer, libcurl 7.29.0 through 7.71.1 can use the wrong connection when sending data.

A flaw was found in the way that curl sanitized URLs. The upstream advisory [1] reports:

libcurl is vulnerable to a data injection attack for certain protocols through control characters embedded or percent-encoded in URLs.

When parsing URLs, libcurl's parser is very laxed and liberal and only parses as little as possible and lets as much as possible through as long as it can figure out what to do.

In the specific process when libcurl extracts the file path part from a given URL, it didn't always verify the data or escape control characters properly before it passed the file path on to the protocol-specific code that then would use it for its protocol business.

This passing through of control characters could be exploited by someone who would be able to pass in a handicrafted URL to libcurl. Lots of libcurl using applications let users enter URLs in one form or another and not all of these check the input carefully to prevent malicious ones.

A malicious user might pass in %0d%0a to get treated as CR LF by libcurl, and by using this fact a user can trick for example a POP3 client to delete a message instead of getting it or trick an SMTP server to send an unintended message.

This vulnerability can be used to fool libcurl with the following protocols: IMAP, POP3 and SMTP. There is no known exploit for this problem.

This flaw only affects curl versions 7.20.0 up to and including 7.23.1 It is corrected in 7.24.0 by scanning for a range of "bad codes" in the path part of URLs so that they are rejected before any protocol code even can consider using them.

This flaw has been assigned the name CVE-2012-0036.

[1] http://curl.haxx.se/docs/security.html

Statement:

Not vulnerable. This issue did not affect the versions of curl as shipped with Red Hat Enterprise Linux 4, 5 or 6.

gzip integer overflow

libcurl might in some circumstances reuse the wrong connection when asked to do Negotiate-authenticated ones, even when they are set to use different 'services'.

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 same server that was authenticated using different services.

Music Player Daemon (MPD) before version 0.24.11 contains a server-side request forgery vulnerability in CurlInputPlugin where CURLOPTFOLLOWLOCATION is set without CURLOPTREDIRPROTOCOLSSTR, allowing unauthenticated attackers to bypass the http/https scheme restriction by causing a malicious HTTP server to redirect to non-HTTP protocols such as gopher, ftp, sftp, ldap, dict, rtmp, or rtsp. Attackers can trigger this vulnerability via MPD commands that initiate URL fetches, including add, readcomments, albumart, readpicture, or load, to interact with internal or restricted network services on systems running libcurl versions prior to 7.85.0.

The redirect implementation in curl and libcurl 5.11 through 7.19.3, when CURLOPTFOLLOWLOCATION is enabled, accepts arbitrary Location values, which might allow remote HTTP servers to (1) trigger arbitrary requests to intranet servers, (2) read or overwrite arbitrary files via a redirect to a file: URL, or (3) execute arbitrary commands via a redirect to an scp: URL.

A stack based buffer overflow flaw was found in the way libcurl used to uncompress zlib compressed data. If an application, using libcurl, was downloading compressed content over HTTP and asked libcurl to automatically uncompress data, it might lead to denial of service (application crash) or, potentially, to arbitrary code execution with the privileges of that application.

Upstream advisory: [1] http://curl.haxx.se/docs/adv20100209.html

Upstream patch: [2] http://curl.haxx.se/libcurl-contentencoding.patch

Affected versions of cURL/libCURL (from [1]): 7.10.5 to and including 7.19.7

Other references: [3] http://curl.haxx.se/docs/security.html#20100209 [4] http://curl.haxx.se/download.html

CVE Request: [5] http://www.openwall.com/lists/oss-security/2010/02/09/5

Acknowledgements:

Red Hat would like to thank Daniel Stenberg for responsibly reporting this issue. Upstream acknowledges Wesley Miaw as the original reporter.

A flaw was found in libcurl. An application using libcurl that performs an authenticated HTTP(S) request after a Negotiate-authenticated one to the same host may incorrectly reuse the previous connection. This authentication bypass vulnerability allows the second request to be sent over a connection authenticated with different credentials, potentially leading to unauthorized access or information disclosure.

libcurl might in some circumstances reuse the wrong connection when asked to do Negotiate-authenticated ones, even when they are set to use different "services".

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 same server that was authenticated using different services.

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.

A flaw was found in libcurl. When configured to use a .netrc file for credentials and follow HTTP redirects, libcurl can inadvertently send the password from the initial connection to the redirected host. This sensitive information disclosure occurs when both the original and redirect URLs use clear text HTTP, are performed over the same HTTP proxy, and the same connection is reused. This vulnerability, categorized as an Exposure of Sensitive Information to an Unauthorized Actor (CWE-200), could allow an attacker to obtain user credentials.

cross-proxy Digest auth state leak

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 if the pin is fine, users could unwittingly connect to an impostor server without noticing.

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.

libcurl's ASN1 parser has this utf8asn1str() function used for parsing an ASN.1 UTF-8 string. Itcan detect an invalid field and return error. Unfortunately, when doing so it also invokes free() on a 4 byte localstack buffer. Most modern malloc implementations detect this error and immediately abort. Some however accept the input pointer and add that memory to its list of available chunks. This leads to the overwriting of nearby stack memory. The content of the overwrite is decided by the free() implementation; likely to be memory pointers and a set of flags. The most likely outcome of exploting this flaw is a crash, although it cannot be ruled out that more serious results can be had in special circumstances.

A flaw was found in libcurl. An application using libcurl that performs an authenticated HTTP(S) request after a Negotiate-authenticated one to the same host may incorrectly reuse the previous connection. This authentication bypass vulnerability allows the second request to be sent over a connection authenticated with different credentials, potentially leading to unauthorized access or information disclosure.