Welcome to #curl 8.19.0

[bagder@mastodon.social]

CVE-2026-1965: bad reuse of HTTP Negotiate connection

libcurl can in some circumstances reuse the wrong connection when asked to do an Negotiate-authenticated HTTP or HTTPS request.

https://curl.se/docs/CVE-2026-1965.html

[bagder@mastodon.social]

CVE-2026-3783: token leak with redirect and netrc

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.

[bagder@mastodon.social]

CVE-2026-3784: wrong proxy connection reuse with credentials

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.

https://curl.se/docs/CVE-2026-3784.html

[bagder@mastodon.social]

CVE-2026-3805: use after free in SMB connection reuse

When doing a second SMB request to the same host again, curl would wrongly use a data pointer pointing into already freed memory.

https://curl.se/docs/CVE-2026-3805.html

[bagder@mastodon.social]

As always with curl CVEs, no other resource has the level of detail and exactness about the flaws like the documentation provided at curl.se

[amy@sk.girlthi.ng]

@bagder@mastodon.social i’m surprised this is unlikely to cause crashes given you read and process from potential garbage, is there a specific design choice that makes curl/the functions you’re calling here more resilient against reading garbage?

[bagder@mastodon.social]

The live-streamed video presentation about this #curl release starts in less than two hours at https://www.twitch.tv/curlhacker

[vsz@mastodon.social]

@bagder #curl 8.19.0 Windows builds at https://curl.se/windows/ via https://github.com/curl/curl-for-win/commit/b64e9da1f0a39c4a4a43ec8c316c94d815db83ff

[marekknapek@hachyderm.io]

@bagder Hi Daniel, are you the one who is deciding whether some bug in curl is a CVE or not? As we all know CVE is "just" some other guy's database. And you and your project had a lot of trouble being bombarded by nonsense CVEs in the past.

So, I want to ask: Has the situation improved since then? Are you the authority over curl CVE now?

[bagder@mastodon.social]

@MarekKnapek yes, we are a "CNA" since a while back, which means that we now decide ourselves if a curl flaw is a CVE or not. This has really improved the situation.