| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| When a user invokes curl using a schemeless URL combined with
`--proto-default` sftp (or scp), a disconnect occurs between the tool layer
and libcurl. The tool layer incorrectly infers the URL scheme, which
erroneously bypasses the initialization of critical SSH security options like
CURLOPT_SSH_HOST_PUBLIC_KEY_SHA256 and CURLOPT_SSH_KNOWNHOSTS. Conversely, the
libcurl runtime successfully honors CURLOPT_DEFAULT_PROTOCOL and establishes
the connection via SFTP/SCP as specified. Because the tool layer skipped the
security configuration, these SSH host verification options are silently
omitted, causing curl to connect to an unverified SSH remote host without
throwing an error. |
| The curl logic that works with SASL authentication could end up cleaning up
the GSASL context *twice* without clearing the pointer in between, making it
`free()` the same pointer twice. |
| 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`. |
| libcurl would reuse a previously created connection even when some mTLS config
related option had been changed that should have prohibited reuse.
libcurl keeps previously used connections in a connection pool for subsequent
transfers to reuse if one of them matches the setup. However, some TLS
settings related to client certificates were left out from the configuration
match checks, making them match too easily. In particular options related to
the private key. |
| 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. |
| When asking curl to use a `.netrc` file to find credentials and at the same
time specifying a URL with a username(without a password), like
`https://[email protected]/`, curl could wrongly get and use the password for
*another* user set in the `.netrc` file for that host if such a one exists and
there is no match for the specified user. |
| 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. |
| 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. |
| 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. |
| 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. |
