VuXML ID | Description |
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
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|