Haxx Org behind the curl project, with curl lead developer Daniel Stenberg
Don't miss out!
Thousands of developers use stack.watch to stay informed.Get an email whenever new security vulnerabilities are reported in any Haxx product.
RSS Feeds for Haxx security vulnerabilities
Create a CVE RSS feed including security vulnerabilities found in Haxx products with stack.watch. Just hit watch, then grab your custom RSS feed url.
Products by Haxx Sorted by Most Security Vulnerabilities since 2018
By the Year
In 2026 there have been 18 vulnerabilities in Haxx with an average score of 5.9 out of ten. Last year, in 2025 Haxx had 9 security vulnerabilities published. That is, 9 more vulnerabilities have already been reported in 2026 as compared to last year. Last year, the average CVE base score was greater by 0.13
| Year | Vulnerabilities | Average Score |
|---|---|---|
| 2026 | 18 | 5.90 |
| 2025 | 9 | 6.03 |
| 2024 | 12 | 5.51 |
| 2023 | 21 | 6.81 |
| 2022 | 20 | 6.88 |
| 2021 | 13 | 5.87 |
| 2020 | 6 | 6.33 |
| 2019 | 7 | 7.78 |
| 2018 | 19 | 8.96 |
It may take a day or so for new Haxx vulnerabilities to show up in the stats or in the list of recent security vulnerabilities. Additionally vulnerabilities may be tagged under a different product or component name.
Recent Haxx Security Vulnerabilities
| CVE | Date | Vulnerability | Products |
|---|---|---|---|
| CVE-2026-7168 | May 13, 2026 |
libcurl Proxy Digest Auth Header Leak on Handle ReuseSuccessfully 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`. |
|
| CVE-2026-7009 | May 13, 2026 |
curl: Improper OCSP Stapling Validation Leads to False Trust (CVE-2026-7009)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. |
|
| CVE-2026-6429 | May 13, 2026 |
CURL libcurl HTTP Redirect Password Leak via .netrcWhen asked to both use a `.netrc` file for credentials and to follow HTTP redirects, libcurl could leak the password used for the first host to the followed-to host under certain circumstances. |
|
| CVE-2026-6276 | May 13, 2026 |
Stale Host Header Causes Cookie Leakage in libcurlUsing 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. |
|
| CVE-2026-6253 | May 13, 2026 |
Curl Credential Leak via Proxy Chain Redirectcurl 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 |
|
| CVE-2026-5773 | May 13, 2026 |
libcurl SMB Connection Reuse flaw leads to wrong file transferlibcurl might in some circumstances reuse the wrong connection for SMB(S) transfers. 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 criteria must be met. Due to a logical error in the code, a network transfer operation that was requested by an application could wrongfully reuse an existing SMB connection to the same server that was using a different 'share' than the new subsequent transfer should. This could in unlucky situations lead to the download of the wrong file or the upload of a file to the wrong place. When this happens, the same credentials are used and the server name is the same. |
|
| CVE-2026-5545 | May 13, 2026 |
libcurl Auth Credential Leak via Connection Reuselibcurl might in some circumstances reuse the wrong connection when asked to do an authenticated HTTP(S) request after a Negotiate-authenticated one, when both use the same host. 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 criteria must 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. An application that first uses Negotiate authentication to a server with `user1:password1` and then does another operation to the same server asking for any authentication method but for `user2:password2` (while the previous connection is still alive) - the second request gets confused and wrongly reuses the same connection and sends the new request over that connection thinking it uses a mix of user1's and user2's credentials when it is in fact still using the connection authenticated for user1... |
|
| CVE-2026-4873 | May 13, 2026 |
curl TLS Reuse Vulnerability: Cleartext LeakA 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. |
|
| CVE-2026-3805 | Mar 11, 2026 |
curl SMB UAF: freed memory used on repeated requestWhen doing a second SMB request to the same host again, curl would wrongly use a data pointer pointing into already freed memory. |
|
| CVE-2026-3784 | Mar 11, 2026 |
CURL: Improper HTTP Proxy Connection Reuse with Different Credentialscurl 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. |
|