| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| An issue in curl’s QUIC UDP receive function allows a malicious HTTP/3 server
to trigger a remote denial of service against a curl or libcurl client.
Because the helper function discards zero-length UDP datagrams before counting
them toward the per-call packet budget, a connected QUIC peer can continuously
stream empty datagrams to indefinitely stall the client. |
| By default, curl automatically responds to WebSocket PING frames. Because curl
lacks an upper bound on memory allocation for unacknowledged frames, a
malicious server can exhaust all available memory by flooding curl with rapid,
sequential PING messages. |
| When reusing a libcurl handle for sequential transfers driven by
environment-variable proxy configuration, libcurl fails to clear the proxy
authentication state between requests. Specifically, if the initial transfer
authenticates against `proxyA` using Digest auth, a subsequent transfer routed
through `proxyB` erroneously leaks the `Proxy-Authorization:` header intended
solely for `proxyA`. |
| Calling `curl_easy_pause()` within the event-based `CURLMOPT_SOCKETFUNCTION`
callback triggers a use-after-free vulnerability, where libcurl attempts to
store a flag using a dangling struct pointer immediately after that pointer's
memory has been freed. |
| A vulnerability exists where a new transfer that uses STARTTLS to upgrade the
connection might reuse an existing live connection even though the TLS
configuration mismatches so it should not. |
| libcurl had a flaw that when instructed to clear proxy authentication
credentials which made it not do so, leaving the old credentials around to get
used for subsequent transfers that should not know nor use them. |
| 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`. |
| curl would wrongly reuse an existing HTTP proxy connection doing CONNECT to a
server, even if the new request uses different credentials for the HTTP proxy.
The proper behavior is to create or use a separate connection. |
| curl's code for managing SSH connections when SFTP was done using the wolfSSH
powered backend was flawed and missed host verification mechanisms.
This prevents curl from detecting MITM attackers and more. |
| 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. |
| Using libcurl, when a custom `Host:` header is first set for an 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. |
| 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 bypasses the TLS requirement and instead transmit data
unencrypted. |
| 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 |
| The redirect implementation in curl and libcurl 5.11 through 7.19.3, when CURLOPT_FOLLOWLOCATION 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. |
| lib/ssluse.c in cURL and libcurl 7.4 through 7.19.5, when OpenSSL is used, does not properly handle a '\0' character in a domain name in the subject's Common Name (CN) field of an X.509 certificate, which allows man-in-the-middle attackers to spoof arbitrary SSL servers via a crafted certificate issued by a legitimate Certification Authority, a related issue to CVE-2009-2408. |
| Stack-based buffer overflow in the ntlm_output function in http-ntlm.c for (1) wget 1.10, (2) curl 7.13.2, and (3) libcurl 7.13.2, and other products that use libcurl, when NTLM authentication is enabled, allows remote servers to execute arbitrary code via a long NTLM username. |
| When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer
performs a redirect to a second URL, curl could leak that token to the second
hostname under some circumstances.
If the hostname that the first request is redirected to has information in the
used .netrc file, with either of the `machine` or `default` keywords, curl
would pass on the bearer token set for the first host also to the second one. |
| When doing a second SMB request to the same host again, curl would wrongly use
a data pointer pointing into already freed memory. |
| URLs containing percent-encoded slashes (`/` or `\`) can trick wcurl into
saving the output file outside of the current directory without the user
explicitly asking for it.
This flaw only affects the wcurl command line tool. |
| 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. |
