VuXML ID | Description |
01cf67b3-dc3b-11e2-a6cd-c48508086173 | cURL library -- heap corruption in curl_easy_unescape
cURL developers report:
libcurl is vulnerable to a case of bad checking of the
input data which may lead to heap corruption.
The function curl_easy_unescape() decodes URL-encoded
strings to raw binary data. URL-encoded octets are
represented with %HH combinations where HH is a two-digit
hexadecimal number. The decoded string is written to an
allocated memory area that the function returns to the
caller.
The function takes a source string and a length
parameter, and if the length provided is 0 the function will
instead use strlen() to figure out how much data to
parse.
The "%HH" parser wrongly only considered the case where a
zero byte would terminate the input. If a length-limited
buffer was passed in which ended with a '%' character which
was followed by two hexadecimal digits outside of the buffer
libcurl was allowed to parse alas without a terminating
zero, libcurl would still parse that sequence as well. The
counter for remaining data to handle would then be decreased
too much and wrap to become a very large integer and the
copying would go on too long and the destination buffer that
is allocated on the heap would get overwritten.
We consider it unlikely that programs allow user-provided
strings unfiltered into this function. Also, only the not
zero-terminated input string use case is affected by this
flaw. Exploiting this flaw for gain is probably possible for
specific circumstances but we consider the general risk for
this to be low.
The curl command line tool is not affected by this
problem as it doesn't use this function.
There are no known exploits available at this time.
Discovery 2013-06-22 Entry 2013-06-23 Modified 2013-07-01 curl
ge 7.7 lt 7.24.0_4
CVE-2013-2174
http://curl.haxx.se/docs/adv_20130622.html
|
04f29189-1a05-11e7-bc6e-b499baebfeaf | cURL -- potential memory disclosure
The cURL project reports:
There were two bugs in curl's parser for the command line option
--write-out (or -w for short) that would skip the end of string
zero byte if the string ended in a % (percent) or \ (backslash),
and it would read beyond that buffer in the heap memory and it
could then potentially output pieces of that memory to the
terminal or the target file etc..
This flaw only exists in the command line tool.
We are not aware of any exploit of this flaw.
Discovery 2017-04-03 Entry 2017-04-05 Modified 2017-04-06 curl
ge 6.5 lt 7.53.1_1
https://curl.haxx.se/docs/adv_20170403.html
CVE-2017-7407
|
04fe6c8d-2a34-4009-a81e-e7a7e759b5d2 | cURL -- multiple vulnerabilities
cURL security problems:
CVE-2018-1000300: FTP shutdown response buffer overflow
curl might overflow a heap based memory buffer when closing down an
FTP connection with very long server command replies.
When doing FTP transfers, curl keeps a spare "closure handle" around
internally that will be used when an FTP connection gets shut down
since the original curl easy handle is then already removed.
FTP server response data that gets cached from the original transfer
might then be larger than the default buffer size (16 KB) allocated in
the "closure handle", which can lead to a buffer overwrite. The
contents and size of that overwrite is controllable by the server.
This situation was detected by an assert() in the code, but that was
of course only preventing bad stuff in debug builds. This bug is very
unlikely to trigger with non-malicious servers.
We are not aware of any exploit of this flaw.
CVE-2018-1000301: RTSP bad headers buffer over-read
curl can be tricked into reading data beyond the end of a heap based
buffer used to store downloaded content.
When servers send RTSP responses back to curl, the data starts out
with a set of headers. curl parses that data to separate it into a
number of headers to deal with those appropriately and to find the end
of the headers that signal the start of the "body" part.
The function that splits up the response into headers is called
Curl_http_readwrite_headers() and in situations where it can't find a
single header in the buffer, it might end up leaving a pointer pointing
into the buffer instead of to the start of the buffer which then later
on may lead to an out of buffer read when code assumes that pointer
points to a full buffer size worth of memory to use.
This could potentially lead to information leakage but most likely a
crash/denial of service for applications if a server triggers this flaw.
We are not aware of any exploit of this flaw.
Discovery 2018-05-16 Entry 2018-05-16 curl
< 7.60.0
https://curl.haxx.se/docs/security.html
https://curl.haxx.se/docs/adv_2018-82c2.html
https://curl.haxx.se/docs/adv_2018-b138.html
CVE-2018-1000300
CVE-2018-1000301
|
0cbf0fa6-dcb7-469c-b87a-f94cffd94583 | cURL -- Multiple vulnerabilities
The cURL project reports:
libcurl 7.1 through 7.57.0 might accidentally leak authentication
data to third parties. When asked to send custom headers in its HTTP
requests, libcurl will send that set of headers first to the host in
the initial URL but also, if asked to follow redirects and a 30X HTTP
response code is returned, to the host mentioned in URL in the
`Location:` response header value. Sending the same set of headers to
subsequest hosts is in particular a problem for applications that pass
on custom `Authorization:` headers, as this header often contains
privacy sensitive information or data that could allow others to
impersonate the libcurl-using client's request.
Discovery 2018-01-24 Entry 2018-01-26 curl
< 7.58.0
https://curl.haxx.se/docs/adv_2018-b3bf.html
CVE-2018-1000007
|
0f99a30c-7b4b-11ed-9168-080027f5fec9 | curl -- multiple vulnerabilities
Daniel Stenberg reports:
- CVE-2022-32221: POST following PUT confusion
-
When doing HTTP(S) transfers, libcurl might erroneously
use the read callback
(
CURLOPT_READFUNCTION ) to ask for data to
send, even when the CURLOPT_POSTFIELDS
option has been set, if the same handle previously was
used to issue a PUT request which used that
callback. This flaw may surprise the application and
cause it to misbehave and either send off the wrong data
or use memory after free or similar in the subsequent
POST request. The problem exists in the
logic for a reused handle when it is changed from a PUT
to a POST.
- CVE-2022-35260: .netrc parser out-of-bounds access
-
curl can be told to parse a .netrc file for
credentials. If that file ends in a line with
consecutive non-white space letters and no newline, curl
could read past the end of the stack-based buffer, and
if the read works, write a zero byte possibly beyond its
boundary. This will in most cases cause a segfault or
similar, but circumstances might also cause different
outcomes. If a malicious user can provide a custom netrc
file to an application or otherwise affect its contents,
this flaw could be used as denial-of-service.
- CVE-2022-42915: HTTP proxy double-free
-
f curl is told to use an HTTP proxy for a transfer with
a non-HTTP(S) URL, it sets up the connection to the
remote server by issuing a CONNECT request to the proxy,
and then tunnels the rest of protocol through. An HTTP
proxy might refuse this request (HTTP proxies often only
allow outgoing connections to specific port numbers,
like 443 for HTTPS) and instead return a non-200
response code to the client. Due to flaws in the
error/cleanup handling, this could trigger a double-free
in curl if one of the following schemes were used in the
URL for the transfer: dict, gopher, gophers, ldap,
ldaps, rtmp, rtmps, telnet
- CVE-2022-42916: HSTS bypass via IDN
-
curl's HSTS check could be bypassed to trick it to keep
using HTTP. Using its HSTS support, curl can be
instructed to use HTTPS directly instead of using an
insecure clear-text HTTP step even when HTTP is provided
in the URL. This mechanism could be bypassed if the host
name in the given URL uses IDN characters that get
replaced to ASCII counterparts as part of the IDN
conversion. Like using the character UTF-8 U+3002
(IDEOGRAPHIC FULL STOP) instead of the common ASCII full
stop (U+002E) .. Like this: http://curlãÂÂseãÂÂ
Discovery 2022-10-26 Entry 2022-12-14 curl
< 7.86.0
CVE-2022-32221
CVE-2022-35260
CVE-2022-42915
CVE-2022-42916
https://curl.se/docs/CVE-2022-32221.html
https://curl.se/docs/CVE-2022-35260.html
https://curl.se/docs/CVE-2022-42915.html
https://curl.se/docs/CVE-2022-42916.html
|
11e36890-d28c-11ec-a06f-d4c9ef517024 | curl -- Multiple vulnerabilities
The curl project reports:
CVE-2022-27778: curl removes wrong file on error
CVE-2022-27779: cookie for trailing dot TLD
CVE-2022-27780: percent-encoded path separator in URL host
CVE-2022-27781: CERTINFO never-ending busy-loop
CVE-2022-27782: TLS and SSH connection too eager reuse
CVE-2022-30115: HSTS bypass via trailing dot
Discovery 2022-05-11 Entry 2022-05-13 curl
< 7.83.1
CVE-2022-27778
CVE-2022-27779
CVE-2022-27780
CVE-2022-27781
CVE-2022-27782
CVE-2022-30115
https://curl.se/docs/security.html
|
143ec3d6-b7cf-11e7-ac58-b499baebfeaf | cURL -- out of bounds read
The cURL project reports:
libcurl contains a buffer overrun flaw in the IMAP handler.
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.
Discovery 2017-10-23 Entry 2017-10-23 curl
ge 7.20 lt 7.56.1
https://curl.haxx.se/docs/adv_20171023.html
CVE-2017-1000257
|
2438d4af-1538-11e5-a106-3c970e169bc2 | cURL -- Multiple Vulnerability
cURL reports:
libcurl can wrongly send HTTP credentials when re-using
connections.
libcurl allows applications to set credentials for the
upcoming transfer with HTTP Basic authentication, like
with CURLOPT_USERPWD for example. Name and password.
Just like all other libcurl options the credentials
are sticky and are kept associated with the "handle"
until something is made to change the situation.
Further, libcurl offers a curl_easy_reset() function
that resets a handle back to its pristine state in
terms of all settable options. A reset is of course
also supposed to clear the credentials. A reset is
typically used to clear up the handle and prepare
it for a new, possibly unrelated, transfer.
Within such a handle, libcurl can also store a
set of previous connections in case a second transfer
is requested to a host name for which an existing
connection is already kept alive.
With this flaw present, using the handle even
after a reset would make libcurl accidentally use
those credentials in a subsequent request if done
to the same host name and connection as was
previously accessed.
An example case would be first requesting a password
protected resource from one section of a web site, and
then do a second request of a public resource from a
completely different part of the site without
authentication. This flaw would then inadvertently
leak the credentials in the second request.
libcurl can get tricked by a malicious SMB server to
send off data it did not intend to.
In libcurl's state machine function handling the SMB
protocol (smb_request_state()), two length and offset
values are extracted from data that has arrived over
the network, and those values are subsequently used
to figure out what data range to send back.
The values are used and trusted without boundary
checks and are just assumed to be valid. This allows
carefully handcrafted packages to trick libcurl
into responding and sending off data that was not
intended. Or just crash if the values cause libcurl
to access invalid memory.
Discovery 2015-06-17 Entry 2015-06-17 curl
ge 7.40 lt 7.43
CVE-2015-3236
CVE-2015-3237
http://curl.haxx.se/docs/adv_20150617A.html
http://curl.haxx.se/docs/adv_20150617B.html
|
27f742f6-03f4-11e5-aab1-d050996490d0 | cURL -- sensitive HTTP server headers also sent to proxies
cURL reports:
libcurl provides applications a way to set custom HTTP
headers to be sent to the server by using CURLOPT_HTTPHEADER.
A similar option is available for the curl command-line
tool with the '--header' option.
When the connection passes through an HTTP proxy the
same set of headers is sent to the proxy as well by default.
While this is by design, it has not necessarily been clear
nor understood by application programmers.
Discovery 2015-04-29 Entry 2015-05-26 curl
< 7.42.1
CVE-2015-3153
http://curl.haxx.se/docs/adv_20150429.html
|
301a01b7-d50e-11e7-ac58-b499baebfeaf | cURL -- Multiple vulnerabilities
The cURL project reports:
- NTLM buffer overflow via integer overflow
(CVE-2017-8816)
libcurl contains a buffer overrun flaw
in the NTLM authentication code.
The internal function Curl_ntlm_core_mk_ntlmv2_hash sums up
the lengths of the user name + password (= SUM) and multiplies
the sum by two (= SIZE) to figure out how large storage to
allocate from the heap.
- FTP wildcard out of bounds read (CVE-2017-8817)
libcurl contains a read out of bounds flaw in the FTP wildcard
function.
libcurl's FTP wildcard matching feature, which is enabled with
the CURLOPT_WILDCARDMATCH 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.
- SSL out of buffer access (CVE-2017-8818)
libcurl contains an out boundary access flaw in SSL related code.
When allocating memory for a connection (the internal struct
called connectdata), a certain amount of memory is allocated at
the end of the struct to be used for SSL related structs. Those
structs are used by the particular SSL library libcurl is built
to use. The application can also tell libcurl which specific SSL
library to use if it was built to support more than one.
Discovery 2017-11-29 Entry 2017-11-29 Modified 2017-12-11 curl
ge 7.21.0 lt 7.57.0
linux-c7-curl
ge 7.21.0 lt 7.29.0_4
https://curl.haxx.se/changes.html
CVE-2017-8816
CVE-2017-8817
CVE-2017-8818
|
311e4b1c-f8ee-11e6-9940-b499baebfeaf | cURL -- ocsp status validation error
The cURL project reports:
SSL_VERIFYSTATUS ignored
curl and libcurl support "OCSP stapling", also known as the TLS
Certificate Status Request extension (using the
CURLOPT_SSL_VERIFYSTATUS option). When telling curl to use this
feature, it uses that TLS extension to ask for a fresh proof of
the server's certificate's validity. If the server doesn't support
the extension, or fails to provide said proof, curl is expected to
return an error.
Due to a coding mistake, the code that checks for a test success or
failure, ends up always thinking there's valid proof, even when
there is none or if the server doesn't support the TLS extension in
question. Contrary to how it used to function and contrary to how
this feature is documented to work.
This could lead to users not detecting when a server's certificate
goes invalid or otherwise be mislead that the server is in a better
shape than it is in reality.
Discovery 2017-02-22 Entry 2017-02-22 curl
ge 7.52.0 lt 7.53.0
https://curl.haxx.se/docs/adv_20170222.html
CVE-2017-2629
|
3849e28f-8693-11e8-9610-9c5c8e75236a | curl -- SMTP send heap buffer overflow
Peter Wu reports:
curl might overflow a heap based memory buffer when sending data over SMTP and using a reduced read buffer.
Discovery 2018-07-11 Entry 2018-07-27 Modified 2018-07-28 curl
ge 7.54.1 lt 7.61.0
https://curl.haxx.se/docs/adv_2018-70a2.html
CVE-2018-0500
|
3c77f139-3a09-11eb-929d-d4c9ef517024 | cURL -- Multiple vulnerabilities
The cURL project reports:
Trusting FTP PASV responses (CVE-2020-8284)
FTP wildcard stack overflow (CVE-2020-8285)
Inferior OCSP verification (CVE-2020-8286)
Discovery 2020-12-09 Entry 2020-12-09 curl
gt 4.0 lt 7.74.0
https://curl.se/docs/security.html
CVE-2020-8284
CVE-2020-8285
CVE-2020-8286
|
3e2e9b44-25ce-11e7-a175-939b30e0836d | cURL -- TLS session resumption client cert bypass (again)
cURL security advisory:
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.
Discovery 2017-04-19 Entry 2017-04-20 curl
ge 7.52.0 lt 7.54.0
CVE-2017-7468
https://curl.haxx.se/docs/adv_20170419.html
|
42880202-c81c-11e6-a9a5-b499baebfeaf | cURL -- buffer overflow
The cURL project reports:
printf floating point buffer overflow
libcurl's implementation of the printf() functions triggers a
buffer overflow when doing a large floating point output. The bug
occurs when the conversion outputs more than 255 bytes.
Discovery 2016-12-21 Entry 2016-12-22 curl
ge 7.1 lt 7.52
https://curl.haxx.se/docs/vuln-7.51.0.html
CVE-2016-9586
|
4e1f4abc-6837-11e3-9cda-3c970e169bc2 | cURL library -- cert name check ignore with GnuTLS
cURL project reports:
libcurl is vulnerable to a case of missing out the checking
of the certificate CN or SAN name field when the digital
signature verification is turned off.
libcurl offers two separate and independent options for
verifying a server's TLS certificate. CURLOPT_SSL_VERIFYPEER
and CURLOPT_SSL_VERIFYHOST. The first one tells libcurl to
verify the trust chain using a CA cert bundle, while the
second tells libcurl to make sure that the name fields in
the server certificate meets the criteria. Both options are
enabled by default.
This flaw had the effect that when an application disabled
CURLOPT_SSL_VERIFYPEER, libcurl mistakenly also skipped the
CURLOPT_SSL_VERIFYHOST check. Applications can disable
CURLOPT_SSL_VERIFYPEER and still achieve security by doing
the check on its own using other means.
The curl command line tool is not affected by this problem
as it either enables both options or disables both at the
same time.
Discovery 2013-12-17 Entry 2013-12-18 curl
ge 7.21.4 lt 7.33.0_2
http://curl.haxx.se/docs/adv_20131217.html
CVE-2013-6422
|
5d433534-f41c-402e-ade5-e0a2259a7cb6 | curl -- cURL/libcURL Location: Redirect URLs Security Bypass
Secunia reports:
The security issue is caused due to cURL following HTTP Location:
redirects to e.g. scp:// or file:// URLs which can be exploited
by a malicious HTTP server to overwrite or disclose the content of
arbitrary local files and potentially execute arbitrary commands via
specially crafted redirect URLs.
Discovery 2009-03-03 Entry 2009-03-04 curl
ge 5.11 lt 7.19.4
CVE-2009-0037
http://secunia.com/advisories/34138/
|
6294f75f-03f2-11e5-aab1-d050996490d0 | cURL -- multiple vulnerabilities
cURL reports:
libcurl keeps a pool of its last few connections around
after use to facilitate easy, convenient, and completely
transparent connection re-use for applications.
When doing HTTP requests NTLM authenticated, the entire
connection becomes authenticated and not just the
specific HTTP request which is otherwise how HTTP works.
This makes NTLM special and a subject for special
treatment in the code. With NTLM, once the connection is
authenticated, no further authentication is necessary until
the connection gets closed.
When doing HTTP requests Negotiate authenticated, the
entire connection may become authenticated and not just
the specific HTTP request which is otherwise how HTTP
works, as Negotiate can basically use NTLM under the hood.
curl was not adhering to this fact but would assume that
such requests would also be authenticated per request.
libcurl supports HTTP "cookies" as documented in RFC 6265.
Together with each individual cookie there are several
different properties, but for this vulnerability we
focus on the associated "path" element. It tells
information about for which path on a given host the
cookies is valid.
The internal libcurl function called sanitize_cookie_path()
that cleans up the path element as given to it from a
remote site or when read from a file, did not properly
validate the input. If given a path that consisted of a
single double-quote, libcurl would index a newly
allocated memory area with index -1 and assign a zero
to it, thus destroying heap memory it wasn't supposed to.
There is a private function in libcurl called fix_hostname()
that removes a trailing dot from the host name if there is
one. The function is called after the host name has been
extracted from the URL libcurl has been told to act on.
If a URL is given with a zero-length host name, like in
"http://:80" or just ":80", fix_hostname() will index the
host name pointer with a -1 offset (as it blindly assumes
a non-zero length) and both read and assign that address.
Discovery 2015-04-22 Entry 2015-05-26 curl
< 7.42.0
http://curl.haxx.se/docs/adv_20150422A.html
http://curl.haxx.se/docs/adv_20150422B.html
http://curl.haxx.se/docs/adv_20150422C.html
http://curl.haxx.se/docs/adv_20150422D.html
CVE-2014-3143
CVE-2014-3144
CVE-2014-3145
CVE-2014-3148
|
69cfa386-7cd0-11e7-867f-b499baebfeaf | cURL -- multiple vulnerabilities
The cURL project reports:
- FILE buffer read out of bounds
- TFTP sends more than buffer size
- URL globbing out of bounds read
Discovery 2017-08-09 Entry 2017-08-09 curl
< 7.55.0
https://curl.haxx.se/docs/security.html
CVE-2017-1000099
CVE-2017-1000100
CVE-2017-1000101
|
6bff5ca6-b61a-11ea-aef4-08002728f74c | curl -- multiple vulnerabilities
curl security problems:
CVE-2020-8169: Partial password leak over DNS on HTTP redirect
libcurl can be tricked to prepend a part of the password to the
host name before it resolves it, potentially leaking the partial
password over the network and to the DNS server(s).
libcurl can be given a username and password for HTTP
authentication when requesting an HTTP resource - used for HTTP
Authentication such as Basic, Digest, NTLM and similar. The
credentials are set, either together with CURLOPT_USERPWD or
separately with CURLOPT_USERNAME and CURLOPT_PASSWORD. Important
detail: these strings are given to libcurl as plain C strings and
they are not supposed to be URL encoded.
In addition, libcurl also allows the credentials to be set in the
URL, using the standard RFC 3986 format:
http://user:password@host/path. In this case, the name and password
are URL encoded as that's how they appear in URLs.
If the options are set, they override the credentials set in the
URL.
Internally, this is handled by storing the credentials in the "URL
object" so that there is only a single set of credentials stored
associated with this single URL.
When libcurl handles a relative redirect (as opposed to an
absolute URL redirect) for an HTTP transfer, the server is only
sending a new path to the client and that path is applied on to the
existing URL. That "applying" of the relative path on top of an
absolute URL is done by libcurl first generating a full absolute
URL out of all the components it has, then it applies the redirect
and finally it deconstructs the URL again into its separate
components.
This security vulnerability originates in the fact that curl did
not correctly URL encode the credential data when set using one of
the curl_easy_setopt options described above. This made curl
generate a badly formatted full URL when it would do a redirect and
the final re-parsing of the URL would then go bad and wrongly
consider a part of the password field to belong to the host name.
The wrong host name would then be used in a name resolve lookup,
potentially leaking the host name + partial password in clear text
over the network (if plain DNS was used) and in particular to the
used DNS server(s).
CVE-2020-8177: curl overwrite local file with -J
curl can be tricked by a malicious server to overwrite a local
file when using -J (--remote-header-name) and -i (--include) in the
same command line.
The command line tool offers the -J option that saves a remote
file using the file name present in the Content-Disposition:
response header. curl then refuses to overwrite an existing local
file using the same name, if one already exists in the current
directory.
The -J flag is designed to save a response body, and so it doesn't
work together with -i and there's logic that forbids it. However,
the check is flawed and doesn't properly check for when the options
are used in the reversed order: first using -J and then -i were
mistakenly accepted.
The result of this mistake was that incoming HTTP headers could
overwrite a local file if one existed, as the check to avoid the
local file was done first when body data was received, and due to
the mistake mentioned above, it could already have received and
saved headers by that time.
The saved file would only get response headers added to it, as it
would abort the saving when the first body byte arrives. A
malicious server could however still be made to send back virtually
anything as headers and curl would save them like this, until the
first CRLF-CRLF sequence appears.
(Also note that -J needs to be used in combination with -O to have
any effect.)
Discovery 2020-06-24 Entry 2020-06-24 curl
ge 7.20.0 lt 7.71.0
https://curl.haxx.se/docs/security.html
https://curl.haxx.se/docs/CVE-2020-8169.html
https://curl.haxx.se/docs/CVE-2020-8177.html
CVE-2020-8169
CVE-2020-8177
|
714b033a-2b09-11e9-8bc3-610fd6e6cd05 | curl -- multiple vulnerabilities
curl security problems:
CVE-2018-16890: NTLM type-2 out-of-bounds buffer read
libcurl contains a heap buffer out-of-bounds read flaw.
The function handling incoming NTLM type-2 messages
(lib/vauth/ntlm.c:ntlm_decode_type2_target) does not validate incoming
data correctly and is subject to an integer overflow vulnerability.
Using that overflow, a malicious or broken NTLM server could trick
libcurl to accept a bad length + offset combination that would lead to a
buffer read out-of-bounds.
CVE-2019-3822: NTLMv2 type-3 header stack buffer overflow
libcurl contains a stack based buffer overflow vulnerability.
The function creating an outgoing NTLM type-3 header
(lib/vauth/ntlm.c:Curl_auth_create_ntlm_type3_message()), generates the
request HTTP header contents based on previously received data. The
check that exists to prevent the local buffer from getting overflowed is
implemented wrongly (using unsigned math) and as such it does not
prevent the overflow from happening.
This output data can grow larger than the local buffer if very large
"nt response" data is extracted from a previous NTLMv2 header provided
by the malicious or broken HTTP server.
Such a "large value" needs to be around 1000 bytes or more. The actual
payload data copied to the target buffer comes from the NTLMv2 type-2
response header.
CVE-2019-3823: SMTP end-of-response out-of-bounds read
libcurl contains a heap out-of-bounds read in the code handling the
end-of-response for SMTP.
If the buffer passed to smtp_endofresp() isn't NUL terminated and
contains no character ending the parsed number, and len is set to 5,
then the strtol() call reads beyond the allocated buffer. The read
contents will not be returned to the caller.
Discovery 2019-02-07 Entry 2019-02-07 curl
< 7.64.0
https://curl.haxx.se/docs/security.html
https://curl.haxx.se/docs/CVE-2018-16890.html
https://curl.haxx.se/docs/CVE-2019-3822.html
https://curl.haxx.se/docs/CVE-2019-3823.html
CVE-2018-16890
CVE-2019-3822
CVE-2019-3823
|
765feb7d-a0d1-11e6-a881-b499baebfeaf | cURL -- multiple vulnerabilities
The cURL project reports
- cookie injection for other servers
- case insensitive password comparison
- OOB write via unchecked multiplication
- double-free in curl_maprintf
- double-free in krb5 code
- glob parser write/read out of bounds
- curl_getdate read out of bounds
- URL unescape heap overflow via integer truncation
- Use-after-free via shared cookies
- invalid URL parsing with '#'
- IDNA 2003 makes curl use wrong host
Discovery 2016-11-02 Entry 2016-11-02 curl
ge 7.1 lt 7.51.0
https://curl.haxx.se/docs/security.html
CVE-2016-8615
CVE-2016-8616
CVE-2016-8617
CVE-2016-8618
CVE-2016-8619
CVE-2016-8620
CVE-2016-8621
CVE-2016-8622
CVE-2016-8623
CVE-2016-8624
CVE-2016-8625
|
8b27f1bc-c509-11e5-a95f-b499baebfeaf | curl -- Credentials not checked
The cURL project reports:
libcurl will reuse NTLM-authenticated proxy connections
without properly making sure that the connection was
authenticated with the same credentials as set for this
transfer.
Discovery 2016-01-27 Entry 2016-01-27 Modified 2017-02-06 curl
ge 7.10.0 lt 7.47.0
http://curl.haxx.se/docs/adv_20160127A.html
CVE-2016-0755
|
92a4d881-c6cf-11ec-a06f-d4c9ef517024 | cURL -- Multiple vulnerabilities
The cURL project reports:
- OAUTH2 bearer bypass in connection re-use (CVE-2022-22576)
- Credential leak on redirect (CVE-2022-27774)
- Bad local IPv6 connection reuse (CVE-2022-27775)
- Auth/cookie leak on redirect (CVE-2022-27776)
Discovery 2022-04-27 Entry 2022-04-28 curl
< 7.83.0
CVE-2022-22576
CVE-2022-27774
CVE-2022-27775
CVE-2022-27776
https://curl.se/docs/vuln-7.82.0.html
|
9314058e-5204-11e7-b712-b1a44a034d72 | cURL -- URL file scheme drive letter buffer overflow
cURL security advisory:
When libcurl is given either
1. a file: URL that doesn't use two slashes following the colon, or
2. is told that file is the default scheme to use for URLs without scheme
... and the given path starts with a drive letter and libcurl is built for
Windows or DOS, then libcurl would copy the path with a wrong offset, so that
the end of the given path would write beyond the malloc buffer. Up to seven
bytes too much.
We are not aware of any exploit of this flaw.
Discovery 2017-06-14 Entry 2017-06-15 curl
ge 7.53.0 lt 7.54.1
CVE-2017-9502
https://curl.haxx.se/docs/adv_20170614.html
|
96df5fd0-8900-11d9-aa18-0001020eed82 | curl -- authentication buffer overflow vulnerability
Two iDEFENSE Security Advisories reports:
An exploitable stack-based buffer overflow condition
exists when using NT Lan Manager (NTLM)
authentication. The problem specifically exists within
Curl_input_ntlm() defined in
lib/http_ntlm.c.
Successful exploitation allows remote attackers to
execute arbitrary code under the privileges of the target
user. Exploitation requires that an attacker either coerce
or force a target to connect to a malicious server using
NTLM authentication.
An exploitable stack-based buffer overflow condition
exists when using Kerberos authentication. The problem
specifically exists within the functions
Curl_krb_kauth() and krb4_auth()
defined in lib/krb4.c.
Successful exploitation allows remote attackers to
execute arbitrary code under the privileges of the target
user. Exploitation requires that an attacker either coerce
or force a target to connect to a malicious server using
Kerberos authentication.
Discovery 2004-12-21 Entry 2005-02-27 curl
< 7.13.1
12615
12616
CVE-2005-0490
http://marc.theaimsgroup.com/?l=bugtraq&m=110902850731457
http://marc.theaimsgroup.com/?l=bugtraq&m=110902601221592
|
9aecb94c-c1ad-11e3-a5ac-001b21614864 | cURL -- inappropriate GSSAPI delegation
cURL reports:
When doing GSSAPI authentication, libcurl unconditionally performs
credential delegation. This hands the server a copy of the client's
security credentials, allowing the server to impersonate the client
to any other using the same GSSAPI mechanism.
Discovery 2011-06-23 Entry 2014-04-11 Modified 2014-04-30 curl
ge 7.10.6 le 7.21.6
linux-f10-curl
ge 7.10.6 le 7.21.6
CVE-2011-2192
http://curl.haxx.se/docs/adv_20110623.html
|
9b4facec-6761-11da-99f6-00123ffe8333 | curl -- URL buffer overflow vulnerability
A Project cURL Security Advisory reports:
libcurl's URL parser function can overflow a malloced
buffer in two ways, if given a too long URL.
1 - pass in a URL with no protocol (like "http://")
prefix, using no slash and the string is 256 bytes or
longer. This leads to a single zero byte overflow of the
malloced buffer.
2 - pass in a URL with only a question mark as separator
(no slash) between the host and the query part of the URL.
This leads to a single zero byte overflow of the malloced
buffer.
Both overflows can be made with the same input string,
leading to two single zero byte overwrites.
The affected flaw cannot be triggered by a redirect, but
the long URL must be passed in "directly" to libcurl. It
makes this a "local" problem. Of course, lots of programs
may still pass in user-provided URLs to libcurl without doing
much syntax checking of their own, allowing a user to exploit
this vulnerability.
Discovery 2005-12-07 Entry 2005-12-09 Modified 2006-01-01 curl
ge 7.11.2 lt 7.15.1
15756
CVE-2005-4077
http://curl.haxx.se/docs/adv_20051207.html
http://www.hardened-php.net/advisory_242005.109.html
http://secunia.com/advisories/17907/
|
9fb4e57b-d65a-11e9-8a5f-e5c82b486287 | curl -- multiple vulnerabilities
curl security problems:
CVE-2019-5481: FTP-KRB double-free
libcurl can be told to use kerberos over FTP to a server, as set with
the CURLOPT_KRBLEVEL option.
During such kerberos FTP data transfer, the server sends data to curl
in blocks with the 32 bit size of each block first and then that amount
of data immediately following.
A malicious or just broken server can claim to send a very large block
and if by doing that it makes curl's subsequent call to realloc() to
fail, curl would then misbehave in the exit path and double-free the
memory.
In practical terms, an up to 4 GB memory area may very well be fine to
allocate on a modern 64 bit system but on 32 bit systems it will fail.
Kerberos FTP is a rarely used protocol with curl. Also, Kerberos
authentication is usually only attempted and used with servers that the
client has a previous association with.
CVE-2019-5482: TFTP small blocksize heap buffer overflow
libcurl contains a heap buffer overflow in the function
(tftp_receive_packet()) that receives data from a TFTP server. It can
call recvfrom() with the default size for the buffer rather than with
the size that was used to allocate it. Thus, the content that might
overwrite the heap memory is controlled by the server.
This flaw is only triggered if the TFTP server sends an OACK without
the BLKSIZE option, when a BLKSIZE smaller than 512 bytes was requested
by the TFTP client. OACK is a TFTP extension and is not used by all
TFTP servers.
Users choosing a smaller block size than default should be rare as the
primary use case for changing the size is to make it larger.
It is rare for users to use TFTP across the Internet. It is most
commonly used within local networks. TFTP as a protocol is always
inherently insecure.
This issue was introduced by the add of the TFTP BLKSIZE option
handling. It was previously incompletely fixed by an almost identical
issue called CVE-2019-5436.
Discovery 2019-09-11 Entry 2019-09-14 curl
ge 7.19.4 lt 7.66.0
https://curl.haxx.se/docs/security.html
https://curl.haxx.se/docs/CVE-2019-5481.html
https://curl.haxx.se/docs/CVE-2019-5482.html
CVE-2019-5481
CVE-2019-5482
|
aa646c01-ea0d-11eb-9b84-d4c9ef517024 | cURL -- Multiple vulnerabilities
The cURL project reports:
CURLOPT_SSLCERT mixup with Secure Transport (CVE-2021-22926)
TELNET stack contents disclosure again (CVE-2021-22925)
Bad connection reuse due to flawed path name checks (CVE-2021-92254)
Metalink download sends credentials (CVE-2021-92253)
Wrong content via metalink not discarded (CVE-2021-92252)
Discovery 2021-07-21 Entry 2021-07-21 curl
< 7.78.0
CVE-2021-22922
CVE-2021-22923
CVE-2021-22924
CVE-2021-22925
CVE-2021-22926
https://curl.se/docs/vuln-7.77.0.html
|
ae5722a6-f5f0-11ec-856e-d4c9ef517024 | cURL -- Multiple vulnerabilities
The cURL project reports:
- CVE-2022-32205: Set-Cookie denial of service
- CVE-2022-32206: HTTP compression denial of service
- CVE-2022-32207: Unpreserved file permissions
- CVE-2022-32208: FTP-KRB bad message verification
Discovery 2022-06-27 Entry 2022-06-27 curl
ge 7.16.4 lt 7.84.0
CVE-2022-32205
CVE-2022-32206
CVE-2022-32207
CVE-2022-32208
https://curl.se/docs/security.html
|
b018121b-7a4b-11e6-bf52-b499baebfeaf | cURL -- Escape and unescape integer overflows
The cURL project reports
The four libcurl functions curl_escape(), curl_easy_escape(),
curl_unescape and curl_easy_unescape perform string URL percent
escaping and unescaping. They accept custom string length inputs
in signed integer arguments.
The provided string length arguments were not properly checked
and due to arithmetic in the functions, passing in the length
0xffffffff (2^32-1 or UINT_MAX or even just -1) would end up
causing an allocation of zero bytes of heap memory that curl
would attempt to write gigabytes of data into.
Discovery 2016-09-14 Entry 2016-09-14 curl
ge 7.11.1 lt 7.50.3
https://curl.haxx.se/docs/adv_20160914.html
CVE-2016-7167
|
b1194286-958e-11eb-9c34-080027f515ea | curl -- Automatic referer leaks credentials
Daniel Stenberg reports:
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.
libcurl automatically sets the Referer: HTTP request header field
in outgoing HTTP requests if the CURLOPT_AUTOREFERER option is set.
With the curl tool, it is enabled with --referer ";auto".
Discovery 2021-03-31 Entry 2021-04-10 curl
ge 7.1.1 lt 7.76.0
CVE-2021-22876
https://curl.se/docs/CVE-2021-22876.html
|
b8e361b8-b7ff-11da-8414-0013d4a4a40e | curl -- TFTP packet buffer overflow vulnerability
A Project cURL Security Advisory reports:
libcurl uses the given file part of a TFTP URL in a manner that
allows a malicious user to overflow a heap-based memory buffer due
to the lack of boundary check.
This overflow happens if you pass in a URL with a TFTP
protocol prefix ("tftp://"), using a valid host and a path
part that is longer than 512 bytes.
The affected flaw can be triggered by a redirect, if
curl/libcurl is told to follow redirects and an HTTP
server points the client to a tftp URL with the
characteristics described above.
Discovery 2006-03-20 Entry 2006-03-20 Modified 2006-10-05 curl
linux-curl
gt 7.14.1 lt 7.15.3
CVE-2006-1061
http://curl.haxx.se/docs/adv_20060320.html
|
b905dff4-e227-11ea-b0ea-08002728f74c | curl -- expired pointer dereference vulnerability
curl security problems:
CVE-2020-8231: wrong connect-only connection
An application that performs multiple requests with libcurl's multi API
and sets the CURLOPT_CONNECT_ONLY option, might in rare circumstances
experience that when subsequently using the setup connect-only transfer,
libcurl will pick and use the wrong connection - and instead pick
another one the application has created since then.
CURLOPT_CONNECT_ONLY is the option to tell libcurl to not perform an
actual transfer, only connect. When that operation is completed, libcurl
remembers which connection it used for that transfer and "easy handle".
It remembers the connection using a pointer to the internal connectdata
struct in memory.
If more transfers are then done with the same multi handle before the
connect-only connection is used, leading to the initial connect-only
connection to get closed (for example due to idle time-out) while also
new transfers (and connections) are setup, such a new connection might
end up getting the exact same memory address as the now closed
connect-only connection.
If after those operations, the application then wants to use the
original transfer's connect-only setup to for example use
curl_easy_send() to send raw data over that connection, libcurl could
erroneously find an existing connection still being alive at the address
it remembered since before even though this is now a new and different
connection.
The application could then accidentally send data over that connection
which wasn't at all intended for that recipient, entirely unknowingly.
Discovery 2020-08-19 Entry 2020-08-19 curl
ge 7.29.0 lt 7.72.0
https://curl.haxx.se/docs/security.html
https://curl.haxx.se/docs/CVE-2020-8231.html
CVE-2020-8231
|
c40ca16c-4d9f-4d70-8b6c-4d53aeb8ead4 | cURL -- uninitialized random vulnerability
Project curl Security Advisory:
libcurl's (new) internal function that returns a good 32bit
random value was implemented poorly and overwrote the pointer
instead of writing the value into the buffer the pointer
pointed to.
This random value is used to generate nonces for Digest and
NTLM authentication, for generating boundary strings in HTTP
formposts and more. Having a weak or virtually non-existent
random there makes these operations vulnerable.
This function is brand new in 7.52.0 and is the result of an
overhaul to make sure libcurl uses strong random as much as
possible - provided by the backend TLS crypto libraries when
present. The faulty function was introduced in this commit.
We are not aware of any exploit of this flaw.
Discovery 2016-12-23 Entry 2016-12-24 curl
ge 7.52.0 lt 7.52.1
https://curl.haxx.se/docs/adv_20161223.html
CVE-2016-9594
|
c8c31c41-49ed-11df-83fb-0015587e2cc1 | curl -- libcurl buffer overflow vulnerability
The cURL project reports in a security advisory:
Using the affected libcurl version to download compressed
content over HTTP, an application can ask libcurl to
automatically uncompress data. When doing so, libcurl
can wrongly send data up to 64K in size to the callback
which thus is much larger than the documented maximum
size.
An application that blindly trusts libcurl's max limit
for a fixed buffer size or similar is then a possible
target for a buffer overflow vulnerability.
Discovery 2010-02-09 Entry 2010-04-19 curl
ge 7.10.5 lt 7.20.0
CVE-2010-0734
http://curl.haxx.se/docs/adv_20100209.html
http://www.debian.org/security/2010/dsa-2023
http://www.openwall.com/lists/oss-security/2010/02/09/5
|
c9221ec9-17a2-11ec-b335-d4c9ef517024 | cURL -- Multiple vulnerabilities
The cURL project reports:
- UAF and double-free in MQTT sending (CVE-2021-22945)
- Protocol downgrade required TLS bypassed (CVE-2021-22946)
- STARTTLS protocol injection via MITM (CVE-2021-22945)
Discovery 2021-09-15 Entry 2021-09-17 Modified 2021-09-28 curl
ge 7.20.0 lt 7.79.0
CVE-2021-22945
CVE-2021-22946
CVE-2021-22947
https://curl.se/docs/security.html
|
caa98ffd-0a92-40d0-b234-fd79b429157e | cURL -- URL request injection vulnerability
cURL reports:
When libcurl sends a request to a server via a HTTP proxy, it
copies the entire URL into the request and sends if off.
If the given URL contains line feeds and carriage returns those will
be sent along to the proxy too, which allows the program to for
example send a separate HTTP request injected embedded in the URL.
Many programs allow some kind of external sources to set the URL or
provide partial pieces for the URL to ask for, and if the URL as
received from the user is not stripped good enough this flaw allows
malicious users to do additional requests in a way that was not
intended, or just to insert request headers into the request that
the program didn't intend.
We are not aware of any exploit of this flaw.
Discovery 2014-12-25 Entry 2015-01-09 curl
< 7.40.0
CVE-2014-8150
http://curl.haxx.se/docs/adv_20150108B.html
|
ccace707-a8d8-11e7-ac58-b499baebfeaf | cURL -- out of bounds read
The cURL project reports:
FTP PWD response parser out of bounds read
libcurl may read outside of a heap allocated buffer when doing FTP.
When libcurl connects to an FTP server and successfully logs in
(anonymous or not), it asks the server for the current directory with
the PWD command. The server then responds with a 257 response containing
the path, inside double quotes. The returned path name is then kept by
libcurl for subsequent uses.
Due to a flaw in the string parser for this directory name, a directory
name passed like this but without a closing double quote would lead to
libcurl not adding a trailing NUL byte to the buffer holding the name.
When libcurl would then later access the string, it could read beyond
the allocated heap buffer and crash or wrongly access data beyond the
buffer, thinking it was part of the path.
A malicious server could abuse this fact and effectively prevent
libcurl-based clients to work with it - the PWD command is always issued
on new FTP connections and the mistake has a high chance of causing a
segfault.
Discovery 2017-10-04 Entry 2017-10-04 curl
< 7.56.0
https://curl.haxx.se/docs/adv_20171004.html
CVE-2017-1000254
|
d10fc771-958f-11eb-9c34-080027f515ea | curl -- TLS 1.3 session ticket proxy host mixup
Daniel Stenberg reports:
Enabled by default, libcurl supports the use of TLS 1.3 session
tickets to resume previous TLS sessions to speed up subsequent
TLS handshakes.
When using a HTTPS proxy and TLS 1.3, libcurl can confuse session
tickets arriving from the HTTPS proxy but work as if they arrived
from the remote server and then wrongly "short-cut" the host
handshake. The reason for this confusion is the modified sequence
from TLS 1.2 when the session ids would provided only during the
TLS handshake, while in TLS 1.3 it happens post hand-shake and
the code was not updated to take that changed behavior into account.
When confusing the tickets, a HTTPS proxy can trick libcurl to use
the wrong session ticket resume for the host and thereby circumvent
the server TLS certificate check and make a MITM attack to be
possible to perform unnoticed.
This flaw can allow a malicious HTTPS proxy to MITM the traffic.
Such a malicious HTTPS proxy needs to provide a certificate that
curl will accept for the MITMed server for an attack to work -
unless curl has been told to ignore the server certificate check.
Discovery 2021-03-31 Entry 2021-04-10 curl
ge 7.63.0 lt 7.76.0
CVE-2021-22890
https://curl.se/docs/CVE-2021-22890.html
|
dd343a2b-7ee7-11e9-a290-8ddc52868fa9 | curl -- multiple vulnerabilities
curl security problems:
CVE-2019-5435: Integer overflows in curl_url_set()
libcurl contains two integer overflows in the curl_url_set()
function that if triggered, can lead to a too small buffer
allocation and a subsequent heap buffer overflow.
The flaws only exist on 32 bit architectures and require
excessive string input lengths.
CVE-2019-5436: TFTP receive buffer overflow
libcurl contains a heap buffer overflow in the function
(tftp_receive_packet()) that recevives data from a TFTP server. It
calls recvfrom() with the default size for the buffer rather than
with the size that was used to allocate it. Thus, the content that
might overwrite the heap memory is entirely controlled by the server.
The flaw exists if the user selects to use a "blksize" of 504 or
smaller (default is 512). The smaller size that is used, the larger
the possible overflow becomes.
Users chosing a smaller size than default should be rare as the
primary use case for changing the size is to make it larger.
It is rare for users to use TFTP across the Internet. It is most
commonly used within local networks.
Discovery 2019-05-22 Entry 2019-05-25 Modified 2019-05-26 curl
ge 7.19.4 lt 7.65.0
https://curl.haxx.se/docs/security.html
https://curl.haxx.se/docs/CVE-2019-5435.html
https://curl.haxx.se/docs/CVE-2019-5436.html
CVE-2019-5435
CVE-2019-5436
|
e0ab1773-07c1-46c6-9170-4c5e81c00927 | curl -- multiple vulnerabilities
curl security problems:
CVE-2018-16839: SASL password overflow via integer overflow
libcurl contains a buffer overrun in the SASL authentication code.
The internal function Curl_auth_create_plain_message fails to
correctly verify that the passed in lengths for name and password
aren't too long, then calculates a buffer size to allocate.
On systems with a 32 bit size_t, the math to calculate the buffer size
triggers an integer overflow when the user name 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 very similar to CVE-2017-14618.
It affects curl 7.33.0 to 7.61.1.
CVE-2018-16840: use-after-free in handle close
libcurl contains a heap use-after-free flaw in code related to closing
an easy handle.
When closing and cleaning up an "easy" handle in the Curl_close()
function, the library code first frees a struct (without nulling the
pointer) and might then subsequently erroneously write to a struct
field within that already freed struct.
It affects curl 7.59.0 to 7.61.1.
CVE-2018-16842: warning message out-of-buffer read
curl contains a heap out of buffer read vulnerability.
The command line tool has a generic function for displaying warning
and informational messages to stderr for various situations. For
example if an unknown command line argument is used, or passed to it in
a "config" file.
This display function formats the output to wrap at 80 columns. The
wrap logic is however flawed, so if a single word in the message is
itself longer than 80 bytes the buffer arithmetic calculates the
remainder wrong and will end up reading behind the end of the buffer.
This could lead to information disclosure or crash.
This vulnerability could lead to a security issue if used in this or
similar situations:
1. a server somewhere uses the curl command line to run something
2. if it fails, it shows stderr to the user
3. the server takes user input for parts of its command line input
4. user provides something overly long that triggers this crash
5. the stderr output may now contain user memory contents that wasn't
meant to be available
It affects curl 7.14.1 to 7.61.1.
Discovery 2018-10-31 Entry 2018-11-01 curl
ge 7.14.1 lt 7.60.0
https://curl.haxx.se/docs/security.html
https://curl.haxx.se/docs/CVE-2018-16839.html
https://curl.haxx.se/docs/CVE-2018-16840.html
https://curl.haxx.se/docs/CVE-2018-16842.html
CVE-2018-16839
CVE-2018-16840
CVE-2018-16842
|
e4bc70fc-5a2f-11e6-a1bc-589cfc0654e1 | Vulnerabilities in Curl
Curl security team reports:
CVE-2016-5419 - TLS session resumption client cert bypass
CVE-2016-5420 - Re-using connections with wrong client cert
CVE-2016-5421 - use of connection struct after free
Discovery 2016-08-03 Entry 2016-08-04 curl
ge 7.32.0 lt 7.50.1
CVE-2016-5419
CVE-2016-5420
CVE-2016-5421
https://curl.haxx.se/docs/adv_20160803A.html
https://curl.haxx.se/docs/adv_20160803B.html
https://curl.haxx.se/docs/adv_20160803C.html
|
f4d638b9-e6e5-4dbe-8c70-571dbc116174 | curl -- password overflow vulnerability
curl security problems:
CVE-2018-14618: NTLM password overflow via integer overflow
The internal function Curl_ntlm_core_mk_nt_hash 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 size_t, 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.
Discovery 2018-09-05 Entry 2018-09-05 Modified 2019-08-03 curl
ge 7.15.4 lt 7.61.1
linux-c7-curl
< 7.29.0_6
https://curl.haxx.se/docs/security.html
https://curl.haxx.se/docs/CVE-2018-14618.html
CVE-2018-14618
|