Filtered by vendor Haxx
Subscriptions
Filtered by product Curl
Subscriptions
Total
143 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2017-8816 | 3 Debian, Haxx, Redhat | 4 Debian Linux, Curl, Libcurl and 1 more | 2026-04-15 | 9.8 Critical |
| The NTLM authentication feature in curl and libcurl before 7.57.0 on 32-bit platforms allows attackers to cause a denial of service (integer overflow and resultant buffer overflow, and application crash) or possibly have unspecified other impact via vectors involving long user and password fields. | ||||
| CVE-2016-8620 | 2 Haxx, Redhat | 2 Curl, Rhel Software Collections | 2026-04-15 | N/A |
| The 'globbing' feature in curl before version 7.51.0 has a flaw that leads to integer overflow and out-of-bounds read via user controlled input. | ||||
| CVE-2016-9586 | 2 Haxx, Redhat | 2 Curl, Rhel Software Collections | 2026-04-15 | N/A |
| curl before version 7.52.0 is vulnerable to a buffer overflow when doing a large floating point output in libcurl's implementation of the printf() functions. If there are any application that accepts a format string from the outside without necessary input filtering, it could allow remote attacks. | ||||
| CVE-2016-9594 | 1 Haxx | 1 Curl | 2026-04-15 | N/A |
| curl before version 7.52.1 is vulnerable to an uninitialized random in libcurl's internal function that returns a good 32bit random value. Having a weak or virtually non-existent random value makes the operations that use it vulnerable. | ||||
| CVE-2018-16839 | 4 Canonical, Debian, Haxx and 1 more | 4 Ubuntu Linux, Debian Linux, Curl and 1 more | 2026-04-15 | N/A |
| Curl versions 7.33.0 through 7.61.1 are vulnerable to a buffer overrun in the SASL authentication code that may lead to denial of service. | ||||
| CVE-2018-16842 | 4 Canonical, Debian, Haxx and 1 more | 6 Ubuntu Linux, Debian Linux, Curl and 3 more | 2026-04-15 | N/A |
| Curl versions 7.14.1 through 7.61.1 are vulnerable to a heap-based buffer over-read in the tool_msgs.c:voutf() function that may result in information exposure and denial of service. | ||||
| CVE-2025-14524 | 2 Curl, Haxx | 2 Curl, Curl | 2026-04-02 | 5.3 Medium |
| 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. | ||||
| CVE-2026-1965 | 2 Curl, Haxx | 2 Curl, Curl | 2026-03-20 | 6.5 Medium |
| libcurl can in some circumstances reuse the wrong connection when asked to do an Negotiate-authenticated HTTP or HTTPS request. libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criterion must first be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different credentials. One underlying reason being that Negotiate sometimes authenticates *connections* and not *requests*, contrary to how HTTP is designed to work. An application that allows Negotiate authentication to a server (that responds wanting Negotiate) with `user1:password1` and then does another operation to the same server also using Negotiate but with `user2:password2` (while the previous connection is still alive) - the second request wrongly reused the same connection and since it then sees that the Negotiate negotiation is already made, it just sends the request over that connection thinking it uses the user2 credentials when it is in fact still using the connection authenticated for user1... The set of authentication methods to use is set with `CURLOPT_HTTPAUTH`. Applications can disable libcurl's reuse of connections and thus mitigate this problem, by using one of the following libcurl options to alter how connections are or are not reused: `CURLOPT_FRESH_CONNECT`, `CURLOPT_MAXCONNECTS` and `CURLMOPT_MAX_HOST_CONNECTIONS` (if using the curl_multi API). | ||||
| CVE-2026-3783 | 2 Curl, Haxx | 2 Curl, Curl | 2026-03-20 | 5.3 Medium |
| 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. | ||||
| CVE-2026-3805 | 2 Curl, Haxx | 2 Curl, Curl | 2026-03-20 | 7.5 High |
| When doing a second SMB request to the same host again, curl would wrongly use a data pointer pointing into already freed memory. | ||||
| CVE-2025-0665 | 3 Curl, Haxx, Netapp | 15 Curl, Libcurl, Curl and 12 more | 2026-03-17 | 7 High |
| libcurl would wrongly close the same eventfd file descriptor twice when taking down a connection channel after having completed a threaded name resolve. | ||||
| CVE-2025-11563 | 2 Curl, Haxx | 3 Curl, Wcurl, Curl | 2026-02-26 | 4.6 Medium |
| 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. | ||||
| CVE-2023-27533 | 5 Fedoraproject, Haxx, Netapp and 2 more | 15 Fedora, Curl, Active Iq Unified Manager and 12 more | 2026-02-13 | 9.8 Critical |
| A vulnerability in input validation exists in curl <8.0 during communication using the TELNET protocol may allow an attacker to pass on maliciously crafted user name and "telnet options" during server negotiation. The lack of proper input scrubbing allows an attacker to send content or perform option negotiation without the application's intent. This vulnerability could be exploited if an application allows user input, thereby enabling attackers to execute arbitrary code on the system. | ||||
| CVE-2023-23915 | 4 Haxx, Netapp, Redhat and 1 more | 13 Curl, Active Iq Unified Manager, Clustered Data Ontap and 10 more | 2026-02-13 | 6.5 Medium |
| A cleartext transmission of sensitive information vulnerability exists in curl <v7.88.0 that could cause HSTS functionality to behave incorrectly when multiple URLs are requested in parallel. Using its HSTS support, curl can be instructed to use HTTPS instead of using an insecure clear-text HTTP step even when HTTP is provided in the URL. This HSTS mechanism would however surprisingly fail when multiple transfers are done in parallel as the HSTS cache file gets overwritten by the most recentlycompleted transfer. A later HTTP-only transfer to the earlier host name would then *not* get upgraded properly to HSTS. | ||||
| CVE-2023-28322 | 5 Apple, Fedoraproject, Haxx and 2 more | 17 Macos, Fedora, Curl and 14 more | 2026-02-13 | 5.3 Medium |
| An information disclosure vulnerability exists in curl <v8.1.0 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 wasused 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 second transfer. The problem exists in the logic for a reused handle when it is (expected to be) changed from a PUT to a POST. | ||||
| CVE-2022-43551 | 5 Fedoraproject, Haxx, Netapp and 2 more | 8 Fedora, Curl, Active Iq Unified Manager and 5 more | 2026-02-13 | 7.5 High |
| A vulnerability exists in curl <7.87.0 HSTS check that could be bypassed to trick it to keep using HTTP. Using its HSTS support, curl can be instructed to use HTTPS instead of using an insecure clear-text HTTP step even when HTTP is provided in the URL. However, the HSTS mechanism could be bypassed if the host name in the given URL first 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) `.`. Then in a subsequent request, it does not detect the HSTS state and makes a clear text transfer. Because it would store the info IDN encoded but look for it IDN decoded. | ||||
| CVE-2022-42916 | 5 Apple, Fedoraproject, Haxx and 2 more | 5 Macos, Fedora, Curl and 2 more | 2026-02-13 | 7.5 High |
| In curl before 7.86.0, the HSTS check could be bypassed to trick it into staying with HTTP. Using its HSTS support, curl can be instructed to use HTTPS directly (instead of using an insecure cleartext 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 with ASCII counterparts as part of the IDN conversion, e.g., using the character UTF-8 U+3002 (IDEOGRAPHIC FULL STOP) instead of the common ASCII full stop of U+002E (.). The earliest affected version is 7.77.0 2021-05-26. | ||||
| CVE-2022-32221 | 6 Apple, Debian, Haxx and 3 more | 16 Macos, Debian Linux, Curl and 13 more | 2026-02-13 | 9.8 Critical |
| 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-2025-14017 | 2 Curl, Haxx | 2 Curl, Curl | 2026-01-27 | 6.3 Medium |
| 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. | ||||
| CVE-2025-10148 | 2 Curl, Haxx | 2 Curl, Curl | 2026-01-20 | 5.3 Medium |
| 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. | ||||