Уязвимость утилиты командной строки cURL, связанная с чтением данных за границами буфера в памяти, позволяющая нарушителю вызвать отказ в обслуживании

The libcurl CURLOPT_SSL_VERIFYPEER option was disabled on a subset of requests made by Nest production devices which enabled a potential man-in-the-middle attack on requests to Google cloud services by any host the traffic was routed through.

curl's websocket code did not update the 32 bit mask pattern for each new
 outgoing frame as the specification says. Instead it used a fixed mask that
persisted and was used throughout the entire connection.

A predictable mask pattern allows for a malicious server to induce traffic
between the two communicating parties that could be interpreted by an involved
proxy (configured or transparent) as genuine, real, HTTP traffic with content
and thereby poison its cache. That cached poisoned content could then be
served to all users of that proxy.

When using `CURLOPT_PINNEDPUBLICKEY` option with libcurl or `--pinnedpubkey`
with the curl tool,curl should check the public key of the server certificate
to verify the peer.

This check was skipped in a certain condition that would then make curl allow
the connection without performing the proper check, thus not noticing a
possible impostor. To skip this check, the connection had to be done with QUIC
with ngtcp2 built to use GnuTLS and the user had to explicitly disable the
standard certificate verification.

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.

When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer
performs a cross-protocol redirect to a second URL that uses an IMAP, LDAP,
POP3 or SMTP scheme, curl might wrongly pass on the bearer token to the new
target host.

When doing TLS related transfers with reused easy or multi handles and
altering the  `CURLSSLOPT_NO_PARTIALCHAIN` option, libcurl could accidentally
reuse a CA store cached in memory for which the partial chain option was
reversed. Contrary to the user's wishes and expectations. This could make
libcurl find and accept a trust chain that it otherwise would not.

When doing SSH-based transfers using either SCP or SFTP, and setting the
known_hosts file, libcurl could still mistakenly accept connecting to hosts
*not present* in the specified file if they were added as recognized in the
libssh *global* known_hosts file.

When doing SSH-based transfers using either SCP or SFTP, and asked to do
public key authentication, curl would wrongly still ask and authenticate using
a locally running SSH agent.

1. A cookie is set using the `secure` keyword for `https://target` 
 2. curl is redirected to or otherwise made to speak with `http://target` (same 
   hostname, but using clear text HTTP) using the same cookie set 
 3. The same cookie name is set - but with just a slash as path (`path=\"/\",`).
   Since this site is not secure, the cookie *should* just be ignored.
4. A bug in the path comparison logic makes curl read outside a heap buffer
   boundary

The bug either causes a crash or it potentially makes the comparison come to
the wrong conclusion and lets the clear-text site override the contents of the
secure cookie, contrary to expectations and depending on the memory contents
immediately following the single-byte allocation that holds the path.

The presumed and correct behavior would be to plainly ignore the second set of
the cookie since it was already set as secure on a secure host so overriding
it on an insecure host should not be okay.