eventfd double close

gzip integer overflow

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.

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.

cross-proxy Digest auth state leak

netrc credential leak with reused proxy connection

stale custom cookie host causes cookie leak

Last updated 10 July 2026

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.

libcurl's ASN1 parser code has the GTime2str() function, used for parsing an ASN.1 Generalized Time field. If given an syntactically incorrect field, the parser might end up using -1 for the length of the time fraction, leading to a strlen() getting performed on a pointer to a heap buffer area that is not (purposely) null terminated.

This flaw most likely leads to a crash, but can also lead to heap contents getting returned to the application when CURLINFOCERTINFO (https://curl.se/libcurl/c/CURLINFOCERTINFO.html) is used.

After testing original CVE-2016-5420 patch, it was discovered that libcurl built on top of NSS (Network Security Services) still incorrectly re-uses client certificates if a certificate from file is used for one TLS connection but no certificate is set for a subsequent TLS connection.

The original patch for CVE-2016-5420 has been amended to also contain the attached patch:

https://curl.haxx.se/CVE-2016-5420.patch

Last updated 10 July 2026

cross-proxy Digest auth state leak ==================================

Project curl Security Advisory, April 29 2026 Permalink

VULNERABILITY -------------

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.

INFO ----

An evil proxyB could use this incoming request header field to impersonate the client in communicating with proxyA, as the header contains the authenticated state.

There is nothing in the request details passed to proxyB that reveal the name or the address of proxyA, which mitigates this problem.

This bug is not considered a C mistake (likely to have been avoided had we not been using C).

This flaw does not affect the curl command line tool.

The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2026-7168 to this issue.

CWE-294: Authentication Bypass by Capture-replay

Severity: Medium

AFFECTED VERSIONS -----------------

- Affected versions: curl 7.12.0 to and including 8.19.0 - Not affected versions: curl < 7.12.0 and >= 8.20.0 - Introduced-in: https://github.com/curl/curl/commit/fc6eff13b5414caf6edf

libcurl is used by many applications, but not always advertised as such!

SOLUTION ------------

- Fixed-in: https://github.com/curl/curl/commit/c1cfdf59acbaf9504c45

RECOMMENDATIONS ---------------

We suggest you take one of the following actions immediately, in order of preference:

A - Upgrade curl and libcurl to version 8.20.0

B - Apply the patch to your version and rebuild

C - Avoid reusing handles when changing proxies

TIMELINE ---------

This issue was reported to the curl project on April 27, 2026.

curl 8.20.0 was released on April 29 2026, coordinated with the publication of this advisory.

CREDITS -------

- Reported-by: Muhamad Arga Reksapati - Patched-by: Daniel Stenberg

Thanks a lot!

--

/ daniel.haxx.se || https://rock-solid.curl.dev

stale custom cookie host causes cookie leak ===========================================

Project curl Security Advisory, April 29 2026 Permalink

VULNERABILITY -------------

Using libcurl, when a custom Host: header is first set for a 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.

INFO ----

Setting a custom Host: header is mostly done for debugging purposes when doing clear text HTTP transfers. When using HTTPS, setting a custom hostname like this is not enough for asking for a specific virtual host since then the SNI also needs to be correct. This condition reduces the impact of this flaw, and is probably a contributing factor why no one else found it before this.

The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2026-6276 to this issue.

CWE-346: Origin Validation Error

Severity: Low

AFFECTED VERSIONS -----------------

- Affected versions: from curl 7.71.0 to and including 8.19.0 - Not affected versions: curl < 7.71.0 and >= 8.20.0 - Introduced-in: https://github.com/curl/curl/commit/e15e51384a423be3131

libcurl is used by many applications, but not always advertised as such!

This bug is not considered a C mistake. It is not likely to have been avoided had we not been using C.

This flaw does not affect the curl command line tool.

SOLUTION --------

- Fixed-in: https://github.com/curl/curl/commit/3a19987a87f393d9394fe5ac

RECOMMENDATIONS ---------------

We suggest you take one of the following actions immediately, in order of preference:

A - Upgrade to curl and libcurl 8.20.0

B - Apply the patch and rebuild libcurl

C - Avoid using custom Host: headers

TIMELINE ---------

It was reported to the curl project on April 14th 2026. We contacted distros@openwall on April 23.

libcurl 8.20.0 was released on April 29th 2026, coordinated with the publication of this advisory.

CREDITS -------

- Reported-by: Muhamad Arga Reksapati - Patched-by: Daniel Stenberg

Thanks a lot!

--

/ daniel.haxx.se || https://rock-solid.curl.dev

OCSP stapling bypass with Apple SecTrust ========================================

Project curl Security Advisory, April 29 2026 Permalink

VULNERABILITY -------------

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.

INFO ----

This vulnerability only occurs when the curl meets two specific conditions:

Backend: It is built using an OpenSSL-based backend (including forks like BoringSSL, AWS-LC, LibreSSL, or QuicTLS).

Trust Store: It is used with Apple SecTrust, the feature that allows curl to access the native CA certificate store on Apple operating systems (macOS, iOS, iPadOS, tvOS, and watchOS).

In short, the flaw requires an OpenSSL-linked curl running on an Apple platform using the system's native certificate store.

OCSP stapling is not a widely used feature on the open web, perhaps partly because so many big name sites do not support it.

This bug is not considered a C mistake (likely to have been avoided had we not been using C).

This flaw also affects the curl command line tool.

The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2026-7009 to this issue.

CWE-295: Improper Certificate Validation

Severity: Medium

AFFECTED VERSIONS -----------------

- Affected versions: curl 8.17.0 to and including 8.19.0 - Not affected versions: curl < 8.17.0 and >= 8.20.0 - Introduced-in: https://github.com/curl/curl/commit/eefd03c572996e5d

libcurl is used by many applications, but not always advertised as such!

SOLUTION ------------

- Fixed-in: https://github.com/curl/curl/commit/51905671e07f087e28e57

RECOMMENDATIONS ---------------

We suggest you take one of the following actions immediately, in order of preference:

A - Upgrade curl and libcurl to version 8.20.0

B - Apply the patch to your version and rebuild

C - Avoid the combination OSCP stapling + Apple SecTrust

TIMELINE ---------

This issue was reported to the curl project on April 25, 2026.

curl 8.20.0 was released on April 29 2026, coordinated with the publication of this advisory.

CREDITS -------

- Reported-by: Carlos Carrillo - Patched-by: Stefan Eissing

Thanks a lot!

--

/ daniel.haxx.se || https://rock-solid.curl.dev

proxy credentials leak over redirect-to proxy =============================================

Project curl Security Advisory, April 29 2026 Permalink

VULNERABILITY -------------

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

INFO ----

The credentials are passed on base64 encoded. The receiving proxy gets no hint as for where or how the credentials are valid.

The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2026-6253 to this issue.

CWE-522: Insufficiently Protected Credentials

Severity: Medium

AFFECTED VERSIONS -----------------

This flaw has existed since curl added support for credentials in proxy strings.

- Affected versions: from curl 7.14.1 to and including 8.19.0 - Not affected versions: curl < 7.14.1 and >= 8.20.0 - Introduced-in: https://github.com/curl/curl/commit/3b60bb725913ce

libcurl is used by many applications, but not always advertised as such!

This bug is not considered a C mistake. It is not likely to have been avoided had we not been using C.

This flaw also affects the curl command line tool.

SOLUTION --------

- Fixed-in: https://github.com/curl/curl/commit/188c2f166a20fa97c2325

RECOMMENDATIONS ---------------

We suggest you take one of the following actions immediately, in order of preference:

A - Upgrade to curl and libcurl 8.20.0

B - Apply the patch and rebuild libcurl

C - Avoid using proxies with credentials

TIMELINE ---------

It was reported to the curl project on April 13th 2026. We contacted distros@openwall on April 23.

libcurl 8.20.0 was released on April 29th 2026, coordinated with the publication of this advisory.

CREDITS -------

- Reported-by: Dwij Mehta - Patched-by: Daniel Stenberg

Thanks a lot!

--

/ daniel.haxx.se || https://rock-solid.curl.dev

netrc credential leak with reused proxy connection ==================================================

Project curl Security Advisory, April 29 2026 Permalink

VULNERABILITY -------------

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.

INFO ----

To trigger, this flaw requires that both the original URL and the redirect URL are using clear text http:// URLs, that both are performed over the same HTTP proxy and that the same connection is reused.

Similar to CVE-2024-11053

The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2026-6429 to this issue.

CWE-200: Exposure of Sensitive Information to an Unauthorized Actor

Severity: Medium

AFFECTED VERSIONS -----------------

- Affected versions: from curl 7.14.0 to and including 8.19.0 - Not affected versions: curl < 7.14.0 and >= 8.20.0 - Introduced-in: https://github.com/curl/curl/commit/01165e08e0d131b399fb

libcurl is used by many applications, but not always advertised as such!

This bug is not considered a C mistake. It is not likely to have been avoided had we not been using C.

This flaw does not affect the curl command line tool.

SOLUTION --------

- Fixed-in: https://github.com/curl/curl/commit/b4024bf808bd558026fdc6

RECOMMENDATIONS ---------------

We suggest you take one of the following actions immediately, in order of preference:

A - Upgrade to curl and libcurl 8.20.0

B - Apply the patch and rebuild libcurl

C - Avoid using the combination netrc, HTTP and HTTP proxy

TIMELINE ---------

It was reported to the curl project on April 16th 2026. We contacted distros@openwall on April 23.

libcurl 8.20.0 was released on April 29th 2026, coordinated with the publication of this advisory.

CREDITS -------

- Reported-by: Muhamad Arga Reksapati - Patched-by: Daniel Stenberg

Thanks a lot!

--

/ daniel.haxx.se || https://rock-solid.curl.dev

wrong reuse of SMB connection =============================

Project curl Security Advisory, April 29 2026 Permalink

VULNERABILITY -------------

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 subsequent transfer should.

This could in unlucky situations lead to the download of the wrong file or the upload of a file to the wrong place. When this happens, the same credentials are used and the server name is the same.

INFO ----

curl only supports SMB version 1 and no later version. SMB version 1 is considered insecure and deprecated and is therefore commonly disabled in servers. curl is scheduled to drop support for SMB later in 2026. SMB support is opt-in since 8.20.0.

In this flaw, the code simply erroneously did not consider the share name as a property to match for connection reuse.

The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2026-5773 to this issue.

CWE-488: Exposure of Data Element to Wrong Session

Severity: Low

AFFECTED VERSIONS -----------------

This flaw has existed since curl started to support SMB.

- Affected versions: from curl 7.40.0 to and including 8.19.0 - Not affected versions: curl < 7.40.0 and >= 8.20.0 - Introduced-in: https://github.com/curl/curl/commit/aec2e865f0

libcurl is used by many applications, but not always advertised as such!

This bug is not considered a C mistake. It is not likely to have been avoided had we not been using C.

This flaw also affects the curl command line tool.

SOLUTION --------

curl 8.20.0 makes sure that connections using SMB never get reused.

- Fixed-in: https://github.com/curl/curl/commit/74a169575d6412d

RECOMMENDATIONS ---------------

We suggest you take one of the following actions immediately, in order of preference:

A - Upgrade to curl and libcurl 8.20.0

B - Apply the patch and rebuild libcurl

C - Avoid using SMB

TIMELINE ---------

It was reported to the curl project on April 5th 2026. We contacted distros@openwall on April 23.

libcurl 8.20.0 was released on April 29th 2026, coordinated with the publication of this advisory.

CREDITS -------

- Reported-by: Osama Hamad - Patched-by: Daniel Stenberg

Thanks a lot!

--

/ daniel.haxx.se || https://rock-solid.curl.dev

wrong reuse of HTTP Negotiate connection ========================================

Project curl Security Advisory, April 29 2026 Permalink

VULNERABILITY -------------

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

An application that first uses Negotiate authentication to a server with user1:password1 and then does another operation to the same server asking for any authentication method but for user2:password2 (while the previous connection is still alive) - the second request gets confused and wrongly reuses the same connection and sends the new request over that connection thinking it uses a mix of user1's and user2's credentials when it is in fact still using the connection authenticated for user1...

INFO ----

The set of authentication methods to use is set with CURLOPTHTTPAUTH.

Applications can disable libcurl's reuse of connections and thus mitigate this problem, by using one of the following libcurl options to alter how connections are or are not reused: CURLOPTFRESHCONNECT, CURLOPTMAXCONNECTS and CURLMOPTMAXHOSTCONNECTIONS (if using the curlmulti API).

The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2026-5545 to this issue.

This flaw is similar to CVE-2026-1965.

CWE-305: Authentication Bypass by Primary Weakness

Severity: Medium

AFFECTED VERSIONS -----------------

This flaw has existed since curl started to support Negotiate.

- Affected versions: from curl 7.10.6 to and including 8.19.0 - Not affected versions: curl < 7.10.6 and >= 8.20.0 - Introduced-in: https://github.com/curl/curl/commit/e56ae1426c

libcurl is used by many applications, but not always advertised as such!

This bug is not considered a C mistake. It is not likely to have been avoided had we not been using C.

This flaw also affects the curl command line tool.

SOLUTION --------

curl 8.20.0 makes sure that connections using Negotiate are not wrongly reused.

- Fixed-in: https://github.com/curl/curl/commit/33e43985b8f3b9e6669

RECOMMENDATIONS ---------------

We suggest you take one of the following actions immediately, in order of preference:

A - Upgrade to curl and libcurl 8.20.0

B - Apply the patch and rebuild libcurl

C - Avoid using HTTP Negotiate in your application

TIMELINE ---------

It was reported to the curl project on April 1st 2026. We contacted distros@openwall on April 23.

libcurl 8.20.0 was released on April 29th 2026, coordinated with the publication of this advisory.

CREDITS -------

- Reported-by: Quac Tran and Ngoc Hieu - Patched-by: Stefan Eissing

Thanks a lot!

--

/ daniel.haxx.se || https://rock-solid.curl.dev

connection reuse ignores TLS requirement ========================================

Project curl Security Advisory, April 29 2026 Permalink

VULNERABILITY -------------

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 will bypass the TLS requirement and instead transmit data unencrypted.

INFO ----

This flaw requires a rather special series of events to trigger. Such a series is unlikely to be used much in the wild.

This issue only happens for transfers done using IMAP://, POP3:// or SMTP:// URL schemes. The initial transfer and the second transfer both need to be done to the same host, use the same credentials and the same URL schemes. The login and the initial transfer is done over clear-text, so the user is obviously already accepting an insecure transmission for this. This flaw still makes it worse as the second transfer is intended to be secured by TLS but is not.

The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2026-4873 to this issue.

CWE-319: Cleartext Transmission of Sensitive Information

Severity: Low

AFFECTED VERSIONS -----------------

- Affected versions: curl 7.20.0 to and including 8.19.0 - Not affected versions: curl < 7.20.0 and >= 8.20.0 - Introduced-in: https://github.com/curl/curl/commit/ec3bb8f727405642a

libcurl is used by many applications, but not always advertised as such!

This bug is not considered a C mistake. It is not likely to have been avoided had we not been using C.

This flaw also affects the curl command line tool.

SOLUTION --------

curl 8.20.0 fixes this logical flaw

- Fixed-in: https://github.com/curl/curl/commit/507e7be573b0a76fca597b75

RECOMMENDATIONS ---------------

We suggest you take one of the following actions immediately, in order of preference:

A - Upgrade to curl and libcurl 8.20.0

B - Apply the patch and rebuild libcurl

C - Do not use clear-text IMAP/POP3/SMTP transfers

TIMELINE ---------

It was reported to the curl project on March 22nd 2026. We contacted distros@openwall on April 23.

libcurl 8.20.0 was released on April 29th 2026, coordinated with the publication of this advisory.

CREDITS -------

- Reported-by: Arkadi Vainbrand - Patched-by: Daniel Stenberg

Thanks a lot!

--

/ daniel.haxx.se || https://rock-solid.curl.dev

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