When doing a second SMB request to the same host again, curl would wrongly use a data pointer pointing into already freed memory.
Accessibility. This issue was addressed through improved state management.
bad reuse of HTTP Negotiate connection
use after free in SMB connection reuse ======================================
Project curl Security Advisory, March 11th 2026 Permalink
VULNERABILITY -------------
When doing a second SMB request to the same host again, curl would wrongly use a data pointer pointing into already freed memory.
INFO ----
When the bad code hits, curl first makes a strlen() on the (freed) memory pointer, then checks that the size is less than or equal than 1024 for it to do something.
Then it copies that string to the the outgoing package which then potentially could leak sensitive data if the application happened to put it there in the mean time since the previous transfer.
This seems extremely hard for an attacker to willingly abuse or to massage the application into leaking specific information. It also seems highly unlikely that any application ever did this sequence without getting a crash or another issue that would indicate there is a problem in curl. The risk here is therefore minimal.
The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2026-3805 to this issue.
CWE-416: Use After Free
Severity: Medium
AFFECTED VERSIONS -----------------
- Affected versions: curl 8.13.0 to and including 8.18.0 - Not affected versions: curl < 8.13.0 and >= 8.19.0 - Introduced-in: https://github.com/curl/curl/commit/f4831daa9b2a97e8a29
libcurl is used by many applications, but not always advertised as such!
This bug is considered a C mistake. It is likely to have been avoided had we not been using C.
This flaw also affects the curl command line tool.
SOLUTION --------
curl 8.19.0 fixes this flaw
- Fixed-in: https://github.com/curl/curl/commit/e090be9f73a7a71459ef678c
RECOMMENDATIONS ---------------
We suggest you take one of the following actions immediately, in order of preference:
A - Upgrade to curl and libcurl 8.19.0
B - Apply the patch and rebuild libcurl
C - Do not use SMB transfers
TIMELINE ---------
It was reported to the curl project on March 8th 2026. We contacted distros@openwall on March 8.
libcurl 8.19.0 was released on March 11th 2026, coordinated with the publication of this advisory.
CREDITS -------
- Reported-by: Daniel Wade - Patched-by: Stefan Eissing
Thanks a lot!
--
/ daniel.haxx.se || https://rock-solid.curl.dev
token leak with redirect and netrc ==================================
Project curl Security Advisory, March 11th 2026 Permalink
VULNERABILITY -------------
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.
INFO ----
The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2026-3783 to this issue.
CWE-522: Insufficiently Protected Credentials
Severity: Medium
AFFECTED VERSIONS -----------------
- Affected versions: curl 7.33.0 to and including 8.18.0 - Not affected versions: curl < 7.33.0 and >= 8.19.0 - Introduced-in: https://github.com/curl/curl/commit/06c1bea72faabb6fad4b7ef8
libcurl is used by many applications, but not always advertised as such!
This bug is not considered a C mistake. It is not likely to have been avoided had we not been using C.
This flaw also affects the curl command line tool.
SOLUTION --------
curl 8.19.0 fixes this flaw
- Fixed-in: https://github.com/curl/curl/commit/e3d7401a32a46516c9e5ee877
RECOMMENDATIONS ---------------
We suggest you take one of the following actions immediately, in order of preference:
A - Upgrade to curl and libcurl 8.19.0
B - Apply the patch and rebuild libcurl
C - Avoid using Bearer tokens with redirects
TIMELINE ---------
It was reported to the curl project on March 3rd 2026. We contacted distros@openwall on March 8.
libcurl 8.19.0 was released on March 11th 2026, coordinated with the publication of this advisory.
CREDITS -------
- Reported-by: spectreglobalsec on hackerone - Patched-by: Daniel Stenberg
Thanks a lot!
--
/ daniel.haxx.se || https://rock-solid.curl.dev
bad reuse of HTTP Negotiate connection ======================================
Project curl Security Advisory, March 11th 2026 Permalink
VULNERABILITY -------------
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 CURLOPTHTTPAUTH.
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: CURLOPTFRESHCONNECT, CURLOPTMAXCONNECTS and CURLMOPTMAXHOSTCONNECTIONS (if using the curlmulti API).
INFO ----
The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2026-1965 to this issue.
This flaw is similar to CVE-2014-0015, but that flaw was for NTLM.
CWE-305: Authentication Bypass by Primary Weakness
Severity: Medium
AFFECTED VERSIONS -----------------
This flaw has existed since curl started to support Negotiate.
- Affected versions: from curl 7.10.6 to and including 8.18.0 - Not affected versions: curl < 7.10.6 and >= 8.19.0 - Introduced-in: https://github.com/curl/curl/commit/e56ae1426c
libcurl is used by many applications, but not always advertised as such!
This bug is not considered a C mistake. It is not likely to have been avoided had we not been using C.
This flaw also affects the curl command line tool.
SOLUTION --------
curl 8.19.0 makes sure that connections that may use Negotiate cannot reuse another Negotiate-using connection unless the credentials match.
- Fixed-in: https://github.com/curl/curl/commit/34fa034d9a390c4bd6 - Fixed-in: https://github.com/curl/curl/commit/f1a39f221d57354990
RECOMMENDATIONS ---------------
We suggest you take one of the following actions immediately, in order of preference:
A - Upgrade to curl and libcurl 8.19.0
B - Apply the patch and rebuild libcurl
C - Avoid using HTTP Negotiate in your application
TIMELINE ---------
It was reported to the curl project on February 4th 2026. We contacted distros@openwall on March 8.
libcurl 8.19.0 was released on March 11th 2026, coordinated with the publication of this advisory.
CREDITS -------
- Reported-by: Zhicheng Chen - Patched-by: Daniel Stenberg
Thanks a lot!
--
/ daniel.haxx.se || https://rock-solid.curl.dev
When doing SSH-based transfers using either SCP or SFTP, and setting the knownhosts 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 knownhosts file.
Accelerate. An out-of-bounds read was addressed with improved bounds checking.
libssh key passphrase bypass without agent set ==============================================
Project curl Security Advisory, January 7 2026 - Permalink
VULNERABILITY -------------
When doing SSH-based transfers using either SCP or SFTP, and asked to do public key authentication, curl would wrongly still ask and authenticate using a locally running SSH agent.
INFO ----
This flaw only exists when libcurl is built to use the libssh backend, not the libssh2 based one. This problem happened because libssh has a somewhat surprising API choice where they fall back to agent authentication.
It should be noted that the authentication still only succeeds if the local SSH agent actually has the correct passphrase.
The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2025-15224 to this issue.
CWE-287: Improper Authentication
Severity: Low
AFFECTED VERSIONS -----------------
- Affected versions: curl 7.58.0 to and including 8.17.0 - Not affected versions: curl < 7.58.0 and >= 8.18.0 - Introduced-in: https://github.com/curl/curl/commit/c92d2e14cfb0db662f958effd2ac86f99
libcurl is used by many applications, but not always advertised as such!
This bug is not considered a C mistake. It is not likely to have been avoided had we not been using C.
This flaw also affects the curl command line tool.
SOLUTION ------------
Starting in curl 8.18.0, this mistake is fixed.
- Fixed-in: https://github.com/curl/curl/commit/16d5f2a5660c61cc27bd5f1c7f512391d1c92
RECOMMENDATIONS --------------
A - Upgrade curl to version 8.18.0
B - Build curl with the libssh2 backend
C - Avoid using SFTP or SCP
TIMELINE --------
This issue was reported to the curl project on December 28, 2025. We contacted distros@openwall on December 30, 2025.
curl 8.18.0 was released on January 7 2026 around 07:00 UTC, coordinated with the publication of this advisory.
The curl security team is not aware of any active exploits using this vulnerability.
CREDITS -------
- Reported-by: Harry Sintonen - Patched-by: Harry Sintonen
Thanks a lot!
--
/ daniel.haxx.se || https://rock-solid.curl.dev
Accelerate. An out-of-bounds read was addressed with improved bounds checking.
A flaw was found in the way that curl sanitized URLs. The upstream advisory [1] reports:
libcurl is vulnerable to a data injection attack for certain protocols through control characters embedded or percent-encoded in URLs.
When parsing URLs, libcurl's parser is very laxed and liberal and only parses as little as possible and lets as much as possible through as long as it can figure out what to do.
In the specific process when libcurl extracts the file path part from a given URL, it didn't always verify the data or escape control characters properly before it passed the file path on to the protocol-specific code that then would use it for its protocol business.
This passing through of control characters could be exploited by someone who would be able to pass in a handicrafted URL to libcurl. Lots of libcurl using applications let users enter URLs in one form or another and not all of these check the input carefully to prevent malicious ones.
A malicious user might pass in %0d%0a to get treated as CR LF by libcurl, and by using this fact a user can trick for example a POP3 client to delete a message instead of getting it or trick an SMTP server to send an unintended message.
This vulnerability can be used to fool libcurl with the following protocols: IMAP, POP3 and SMTP. There is no known exploit for this problem.
This flaw only affects curl versions 7.20.0 up to and including 7.23.1 It is corrected in 7.24.0 by scanning for a range of "bad codes" in the path part of URLs so that they are rejected before any protocol code even can consider using them.
This flaw has been assigned the name CVE-2012-0036.
[1] http://curl.haxx.se/docs/security.html
Statement:
Not vulnerable. This issue did not affect the versions of curl as shipped with Red Hat Enterprise Linux 4, 5 or 6.