Where
-Infinity
0
Severity
7.3
Buffer Overflow, Integer Overflow
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L

gzip integer overflow

1 / 2
Source: Microsoft
First published (updated )
Severity
6.5
EPSS
0.06%
Input Validation
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H

App Store. A permissions issue was addressed with additional restrictions.

1 / 23
Source: Apple
First published (updated )
Severity
4.3
EPSS
0.04%
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N

cURL libcurl could allow a remote attacker to obtain sensitive information, caused by a macidn punycode buffer overread flaw in the URL API function curlurlget(). By sending a specially crafted request, an attacker could exploit this vulnerability to obtain sensitive information, and use this information to launch further attacks against the affected system.

1 / 3
Source: IBM
First published (updated )
Severity
3.7
Buffer Overflow, Input Validation
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N

Accessibility. A privacy issue was addressed with improved private data redaction for log entries.

1 / 20
Source: Apple
First published (updated )
Severity
9.8
EPSS
0.18%
Buffer Overflow, Input Validation
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

Accessibility. A privacy issue was addressed with improved private data redaction for log entries.

1 / 22
Source: Apple
First published (updated )
Severity
7.5
Use After Free, Double Free
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

A double free vulnerability exists in libcurl <8.0.0 when sharing HSTS data between separate "handles". This sharing was introduced without considerations for do this sharing across separate threads but there was no indication of this fact in the documentation. Due to missing mutexes or thread locks two threads sharing the same HSTS data could end up doing a double-free or use-after-free.

1 / 3
Source: Microsoft
First published (updated )
Severity
7.7
AV:L/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N

An authentication bypass vulnerability exists in libcurl prior to v8.0.0 where it reuses a previously established SSH connection despite the fact that an SSH option was modified which should have prevented reuse. libcurl maintains a pool of previously used connections to reuse them for subsequent transfers if the configurations match. However two SSH settings were omitted from the configuration check allowing them to match easily potentially leading to the reuse of an inappropriate connection.

1 / 4
Source: Microsoft
First published (updated )
Severity
5.9
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N

An authentication bypass vulnerability exists libcurl <8.0.0 in the connection reuse feature which can reuse previously established connections with incorrect user permissions due to a failure to check for changes in the CURLOPTGSSAPIDELEGATION option. This vulnerability affects krb5/kerberos/negotiate/GSSAPI transfers and could potentially result in unauthorized access to sensitive information. The safest option is to not reuse connections if the CURLOPTGSSAPIDELEGATION option has been changed.

1 / 3
Source: MITRE
First published (updated )
Severity
5.9
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N

An authentication bypass vulnerability exists in libcurl <8.0.0 in the FTP connection reuse feature that can result in wrong credentials being used during subsequent transfers. Previously created connections are kept in a connection pool for reuse if they match the current setup. However certain FTP settings such as CURLOPTFTPACCOUNT CURLOPTFTPALTERNATIVETOUSER CURLOPTFTPSSLCCC and CURLOPTUSESSL were not included in the configuration match checks causing them to match too easily. This could lead to libcurl using the wrong credentials when performing a transfer potentially allowing unauthorized access to sensitive information.

1 / 4
Source: Microsoft
First published (updated )
Severity
7.5
Buffer Overflow, Input Validation
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

curl 7.21.0 to and including 7.73.0 is vulnerable to uncontrolled recursion due to a stack overflow issue in FTP wildcard match parsing.

1 / 5

Remedy

Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability.
First published (updated )
Severity
7.8
Buffer Overflow
AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L

A heap buffer overflow in the TFTP receiving code allows for DoS or arbitrary code execution in libcurl versions 7.19.4 through 7.64.1.

1 / 2
First published (updated )
Severity
7.5
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Last updated 25 August 2025

1 / 3
Source: Ubuntu
First published (updated )
Severity
9.8
Buffer Overflow
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Last updated 25 August 2025

1 / 3
Source: Ubuntu
First published (updated )
Severity
7.5
Integer Overflow
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Last updated 25 August 2025

1 / 3
Source: Ubuntu
First published (updated )
Severity
9.8
Buffer Overflow, Integer Overflow
AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H

curl before version 7.61.1 is vulnerable to a buffer overrun in the NTLM authentication code. The internal function Curlntlmcoremknthash multiplies the length of the password by two (SUM) to figure out how large temporary storage area to allocate from the heap. The length value is then subsequently used to iterate over the password and generate output into the allocated storage buffer. On systems with a 32 bit sizet, the math to calculate SUM triggers an integer overflow when the password length exceeds 2GB (2^31 bytes). This integer overflow usually causes a very small buffer to actually get allocated instead of the intended very huge one, making the use of that buffer end up in a heap buffer overflow. (This bug is almost identical to CVE-2017-8816.)

1 / 3
First published (updated )
Severity
7.5
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

In curl and libcurl 7.52.0 to and including 7.53.1, libcurl would attempt to resume a TLS session even if the client certificate had changed. That is unacceptable since a server by specification is allowed to skip the client certificate check on resume, and may instead use the old identity which was established by the previous certificate (or no certificate). libcurl supports by default the use of TLS session id/ticket to resume previous TLS sessions to speed up subsequent TLS handshakes. They are used when for any reason an existing TLS connection couldn't be kept alive to make the next handshake faster. This flaw is a regression and identical to CVE-2016-5419 reported on August 3rd 2016, but affecting a different version range.

First published (updated )
Severity
9.1
AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:L

An out-of-bounds read in code handling HTTP/2 trailers was found. This could lead to a denial-of-service or an information disclosure in some circumstances.

Affected versions: libcurl 7.49.0 to and including 7.57.0 Not affected versions: libcurl < 7.49.0 and >= 7.58.0

Upstream bug report:

https://github.com/curl/curl/pull/2231

Upstream patch:

https://github.com/curl/curl/commit/fa3dbb9a147488a294.patch

1 / 3
Source: Red Hat
First published (updated )
Severity
9.8
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

libcurl contains a read out of bounds flaw in the FTP wildcard function.

libcurl's FTP wildcard matching feature, which is enabled with the CURLOPTWILDCARDMATCH option can use a built-in wildcard function or a user provided one. The built-in wildcard function has a flaw that makes it not detect the end of the pattern string if it ends with an open bracket ([) but instead it will continue reading the heap beyond the end of the URL buffer that holds the wildcard.

For applications that use HTTP(S) URLs, allow libcurl to handle redirects and have FTP wildcards enabled, this flaw can be triggered by malicious servers that can redirect clients to a URL using such a wildcard pattern.

- Affected versions: libcurl 7.21.0 to and including 7.56.1 - Not affected versions: libcurl < 7.21.0 and >= 7.57.0

1 / 2
Source: Red Hat
First published (updated )
Severity
9.8
Integer Overflow, Buffer Overflow
AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H

curl. An integer overflow existed in curl. This issue was addressed with improved bounds checking.

1 / 3
First published (updated )
Severity
9.1
Buffer Overflow
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H

An IMAP FETCH response line indicates the size of the returned data, in number of bytes. When that response says the data is zero bytes, libcurl would pass on that (non-existing) data with a pointer and the size (zero) to the deliver-data function.

libcurl's deliver-data function treats zero as a magic number and invokes strlen() on the data to figure out the length. The strlen() is called on a heap based buffer that might not be zero terminated so libcurl might read beyond the end of it into whatever memory lies after (or just crash) and then deliver that to the application as if it was actually downloaded.

Introduced with:

https://github.com/curl/curl/commit/ec3bb8f727

External References:

https://curl.haxx.se/docs/adv20171023.html

1 / 2
Source: Red Hat
First published (updated )
Severity
7.5
Buffer Overflow
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

curl. An out-of-bounds read issue existed in the FTP PWD response parsing. This issue was addressed with improved bounds checking.

1 / 3
First published (updated )
Severity
6.5
Infoleak
CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N

curl. An out-of-bounds read was addressed with improved bounds checking.

1 / 3
First published (updated )
Severity
9.8
Integer Overflow
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

The URL percent-encoding decode function in libcurl before 7.51.0 is called curleasyunescape. Internally, even if this function would be made to allocate a unscape destination buffer larger than 2GB, it would return that new length in a signed 32 bit integer variable, thus the length would get either just truncated or both truncated and turned negative. That could then lead to libcurl writing outside of its heap based buffer.

1 / 2
Source: MITRE
First published (updated )
Severity
7.5
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

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

1 / 2
Source: Red Hat
First published (updated )
Severity
8.1
Use After Free
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

A use-after-free vulnerability in libcurl was found. libcurl works with easy handles using the type 'CURL ' that are objects the application creates using curleasyinit(). They are the handles that are all each associated with a single transfer at a time. libcurl also has an internal struct that represents and holds most state that is related to a single connection. An easy handle can hold references to one or many such connection structs depending on the requested operations.

When using libcurl's multi interface, an application performs transfers by adding one or more easy handles to the multi handle and then it can drive all those transfers in parallel.

Due to a flaw, libcurl could leave a pointer to a freed connection struct dangling in an easy handle that was previously added to a multi handle when curlmulticleanup() is called with an easy handle still added to it. This does not seem to cause any notable harm if the handle is then closed properly.

However, if the easy handle would instead get used again with the easy interface and curleasyperform() to do another transfer, it would blindly use the connection struct pointer now pointing to freed memory.

An application could be made to allocate its own fake version of the connect struct, fill in some data and then have the curleasyperform() call do something that clearly was not intended by the original code.

External Reference:

https://curl.haxx.se/docs/adv20160803C.html

1 / 2
Source: Red Hat
First published (updated )
Severity
7.5
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

curl and libcurl before 7.50.1 do not check the client certificate when choosing the TLS connection to reuse, which might allow remote attackers to hijack the authentication of the connection by leveraging a previously created connection with a different client certificate.

1 / 3
First published (updated )
Severity
7.5
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

curl and libcurl before 7.50.1 do not prevent TLS session resumption when the client certificate has changed, which allows remote attackers to bypass intended restrictions by resuming a session.

1 / 2
Source: MITRE
First published (updated )
Severity
4
Input Validation
AV:N/AC:H/Au:N/C:P/I:P/A:N

curl and libcurl 7.27.0 through 7.35.0, when running on Windows and using the SChannel/Winssl TLS backend, does not verify that the server hostname matches a domain name in the subject's Common Name (CN) or subjectAltName field of the X.509 certificate when accessing a URL that uses a numerical IP address, which allows man-in-the-middle attackers to spoof servers via an arbitrary valid certificate.

First published (updated )
Severity
6.4
AV:N/AC:L/Au:N/C:P/I:P/A:N

The default configuration in cURL and libcurl 7.10.6 before 7.36.0 re-uses (1) SCP, (2) SFTP, (3) POP3, (4) POP3S, (5) IMAP, (6) IMAPS, (7) SMTP, (8) SMTPS, (9) LDAP, and (10) LDAPS connections, which might allow context-dependent attackers to connect as other users via a request, a similar issue to CVE-2014-0015.

First published (updated )
Severity
5.8
AV:N/AC:M/Au:N/C:P/I:P/A:N

cURL and libcurl 7.1 before 7.36.0, when using the OpenSSL, axtls, qsossl or gskit libraries for TLS, recognize a wildcard IP address in the subject's Common Name (CN) field of an X.509 certificate, which might allow man-in-the-middle attackers to spoof arbitrary SSL servers via a crafted certificate issued by a legitimate Certification Authority.

First published (updated )

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203