Last updated 10 July 2026

Hello friends,

CVE-2026-8286: wrong STARTTLS connection reuse (LOW) https://curl.se/docs/CVE-2026-8286.html

CVE-2026-8458: wrong reuse for different services (LOW) https://curl.se/docs/CVE-2026-8458.html

CVE-2026-8924: traling dot domain super cookie (LOW) https://curl.se/docs/CVE-2026-8924.html

CVE-2026-8925: SASL double-free (MEDIUM) https://curl.se/docs/CVE-2026-8925.html

CVE-2026-8926: password leak with netrc and user in URL (LOW) https://curl.se/docs/CVE-2026-8926.html

CVE-2026-8927: env-set cross-proxy Digest auth state leak (MEDIUM) https://curl.se/docs/CVE-2026-8927.html

CVE-2026-8932: incomplete mTLS config matching in conn reuse (LOW) https://curl.se/docs/CVE-2026-8932.html

CVE-2026-9079: stale proxy password leak (MEDIUM) https://curl.se/docs/CVE-2026-9079.html

CVE-2026-9080: UAF after pause in socket callback (LOW) https://curl.se/docs/CVE-2026-9080.html

CVE-2026-9545: exposing HTTP/3 early data (LOW) https://curl.se/docs/CVE-2026-9545.html

CVE-2026-9546: sending old referer (LOW) https://curl.se/docs/CVE-2026-9546.html

CVE-2026-9547: SSH improper host validation (LOW) https://curl.se/docs/CVE-2026-9547.html

CVE-2026-10536: HTTP/2 stream-dependency tree UAF (LOW) https://curl.se/docs/CVE-2026-10536.html

CVE-2026-11352: QUIC zero-length UDP datagrams busy-loop (LOW) https://curl.se/docs/CVE-2026-11352.html

CVE-2026-11564: Native CA trust persist (LOW) https://curl.se/docs/CVE-2026-11564.html

CVE-2026-11586: WS Auto-PONG memory exhaustion (LOW) https://curl.se/docs/CVE-2026-11586.html

CVE-2026-11856: cross-origin Digest auth state leak (MEDIUM) https://curl.se/docs/CVE-2026-11856.html

CVE-2026-12064: proto-default skips SSH verification (LOW) https://curl.se/docs/CVE-2026-12064.html

--

/ daniel.haxx.se || https://rock-solid.curl.dev

Yes, reporting issues without proper analysis is and always has been grossly negligent.  For that I strongly encourage people to fight fire with fire.  AI assisted reports should always go into a queue which utilize agentic analysis.  I can't stress enough how effective this and we should stop shaking our fists at the inevitable.

Everyone also needs to appreciate the amount of donated tokens and money.  When I reported my dozen issues, I burned through very significant quota (much of it verifying).  That was a real $$ donation I made to the project.

ROI AI

From: Markus Klyver <markusklyver () hotmail com> To: "oss-security () lists openwall com"<oss-security () lists openwall com> Date: Fri, 22 May 2026 08:18:35 -0700 Subject: Sv: [oss-security] Coordinated Disclosure in the LLM Age

And my point is that it is up to the submitter to make sure that the bug exists and is real. I also agree that, in practice, embargoes are not costless coordination mechanisms. They impose delays, administrative overhead and a nontrivial burden on maintainers who must preserve confidentiality/track disclosure windows/manage downstream communication. Public reporting means validation, encourage duplicate detection as a signal of prevalence and improve collective defensive awareness once a responsible disclosure process has been satisfied. Från: ROI AI < mailto:sales () roiai ca > Skickat: den 16 maj 2026 01:52 Till: oss-security < mailto:oss-security () lists openwall com > Ämne: Sv: [oss-security] Coordinated Disclosure in the LLM Age Not sure I understand this feedback. Openstack has a lot of low hanging vulnerabilities due to legacy code. This is the central issue, not me or LLMs. A lot of people are clamoring for sovereign cloud right now: https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnews.ycombinator.com%2Fitem%3Fid%3D48120629&data=05%7C02%7C%7C973c98c5b1bd4aa480ea08deb2e10414%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C639144876663331996%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=aM7HS448XCDx0Vl51hCEeL8pS8e%2F8SoxiOTR8KULJmk%3D&reserved=0 < https://news.ycombinator.com/item?id=48120629 > An example: https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.launchpad.net%2Fswift%2F%2Bbug%2F2152384%2Fcomments%2F14&data=05%7C02%7C%7C973c98c5b1bd4aa480ea08deb2e10414%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C639144876663352635%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=qIeyDjkamPlFaLlq%2FfQRAIe5OXJjR4xX9%2BJgyHw6l68%3D&reserved=0 < https://bugs.launchpad.net/swift/+bug/2152384/comments/14 > ROI AI From: Markus Klyver < mailto:markusklyver () hotmail com > To: " mailto:oss-security () lists openwall com "< mailto:oss-security () lists openwall com > Date: Fri, 15 May 2026 08:27:57 -0700 Subject: Sv: [oss-security] Coordinated Disclosure in the LLM Age If you want to process your all your internal thoughts and personality through a statistical probabilistic function, then you are of course absolutely entire free to do so. But please keep in mind that LLMs are also overloading open source projects with fake PRs and "fixes" that ruin the codebase (do I have to mention ffmpeg and curl?), the code quality and the lives of everyone. If an LLM is used to find potential bugs, it is up to you to ensure it is a real bug and that you can replicate the behavior. Offloading that part to the LLM and the need for human knowledge is a loss for everyone involved. Från: Tim Shephard < mailto: mailto:tim () roiai ca > Skickat: den 12 maj 2026 03:22 Till: oss-security < mailto: mailto:oss-security () lists openwall com >; fungi < mailto: mailto:fungi () yuggoth org

Ämne: Re: [oss-security] Coordinated Disclosure in the LLM Age Thanks for starting this discussion. I have reported a number of issues recently, including - #2149789, #2150261, #2149775, #2150316 - three of which are identified by the team as critical, and one as high. The oslo rabbit MITM is also critical, IMHO, but I agree it cannot be fixed without potentially breaking many poorly configured deployments and so must be 'Class B'. An awkward situation to be sure, but the solution is understandable. For what it's worth my goal is not to 'mine security gold', rather I am trying to find and test potential solutions for sovereign cloud. More to the point of the thread, I think there is also a more pressing issue adjacent to the disclosure-process question: large, long-lived projects such as OpenStack have a substantial backlog of legacy vulnerabilities and insecure patterns that are now becoming much easier to discover with LLM assistance. That changes the risk calculation. Issues that previously required deep project knowledge, persistence, or specialized tooling may now be within reach of many more people. We should assume adversaries can use the same leverage, including for insider attacks and for chaining individually modest bugs across trust boundaries. In that sense, this feels like a generational security event. The urgent question is not only whether embargoed details might leak through LLM use, but whether maintainers can harden exposed systems faster than attackers can rediscover and combine old weaknesses. That argues for shorter exposure windows, more proactive hardening, and more attention to eliminating vulnerable patterns before they become practical attack paths. Furthermore, it argues for assertive use of modern LLMs, especially for code review and vulnerability discovery. I have volunteered to help with this for the OpenStack VMT, and would be happy to do so again here. Cheers, Tim. PS: LLMs helped with this email, and with more and more of the work I do. I think we need to move forward with these tools more deliberately and less fearfully. Confidential communication. No warranties or commitments unless in a signed agreement. If received in error, notify sender and delete. Unauthorized use prohibited. Confidential communication. No warranties or commitments unless in a signed agreement. If received in error, notify sender and delete. Unauthorized use prohibited. Confidential communication. No warranties or commitments unless in a signed agreement. If received in error, notify sender and delete. Unauthorized use prohibited.

On 5/22/26 00:31, ROI AI wrote: I understand the costs, but simply hanging all the dirty laundry out is counter productive.   Working a change in public without going into sensitive details is reasonable, but pushing vuln reports to public is careless.

[...]

As a further data point backing up this theory: We’re seeing duplicate reports of the same issue found by multiple independent groups that use LLMs, within the embargo period.

-- Jacob From: Jacob Bachmeyer <jcb62281 () gmail com> To: <oss-security () lists openwall com> Date: Thu, 21 May 2026 21:02:51 -0700 Subject: Re: [oss-security] Coordinated Disclosure in the LLM Age

On 5/21/26 01:51, ROI AI wrote: Also the entire nonsense about making the found issues public - this is absurd and just exacerbates the asymmetry problem.

By keeping the reports private, the OSS teams can deal with the issues more on their timeline.

By making them public, they add timeline pressure and enable attackers.

Why are you making it harder on yourself?  It is the opposite of what you want to do. security issues private rather seriously---and that itself has costs. any benefit when the issue was found using a tool to search for issues, due to the risk of someone else using the same tool and finding the same issue.  If that other person is another whitehat, you get a duplicate report.  If that other person is a blackhat, you get an in-the-wild exploit while you were carefully maintaining an embargo. [...]

From: ROI AI < mailto:sales () roiai ca > To: "oss-security"< mailto:oss-security () lists openwall com > Date: Wed, 20 May 2026 22:26:21 -0700 Subject: Re: [oss-security] Coordinated Disclosure in the LLM Age

People are shooting the messengers here.   The fact is - we are going through a generational security event due to the advancement of LLMs. amount of "AI" slop that has buried maintainers of major packages.  Have you forgotten already that curl had to cancel their bug bounty due to excessive "AI" slop submissions? It is also both trivial and extremely effective to use Agentic analysis to filter security reports. be incapable of precise analysis.  I understand talking your own book, but there are serious externalities here and I cannot let this go unanswered. genuine issue?  Now the issue does not get fixed... "AI" hallucinations?  Remember that the same hallucination-prone model might be doing the analysis as made the bogus report.  How, exactly, is a model supposed to recognize its own hallucinations? As for 'duplicates', people are claiming this when I have seen little evidence.  I reported a dozen or so to one major project and no one has yet claimed invalid or duplicate. manages inserting them into a bug tracker.  I am inclined to trust their experience over your hand-waving dismissal. in many projects, sent straight to the bit bucket, especially if found to be invalid.  You should not expect a response informing you that your report is invalid, as most maintainers have likely stopped bothering to send those. Moreover, if 'duplicates' are found, then that is a good signal for prioritization. issue may be "low-hanging fruit" and therefore already quasi-public.  In other words, duplicate reports could be a signal to dump the embargo and move faster to fix the issue.  (Remember that working under embargo has costs?  Those costs can extend the time to patch.) Let's stop talking about how the vulns are found and start fixing them with urgency. (< mailto:sales () roiai ca >) and realize that I am probably debating a slop machine tasked with promoting a product.  I will send this anyway, for the benefit of my fellow humans who will read this discussion and who might---just might---recognize your marketing efforts as the slop they are. ROI AI -- Jacob From: Alan Coopersmith < mailto: mailto:alan.coopersmith () oracle com > To: < mailto: mailto:oss-security () lists openwall com > Date: Wed, 20 May 2026 10:52:37 -0700 Subject: Re: [oss-security] Coordinated Disclosure in the LLM Age

On 4/28/26 07:58, Jeremy Stanley wrote: I'm sorely tempted, both due to the increased volume and the risk of premature disclosure, to just assume that any vulnerability reported as a result of research using an LLM is trivially discoverable by others, and give up trying to pretend there's any point to working it under embargo. Other maintainers under similar floods seem to agree:

Linux kernel: - https://lkml.org/lkml/2026/5/17/896 - https://docs.kernel.org/process/security-bugs.html

DNS servers (BIND, Unbound, PowerDNS): - https://indico.dns-oarc.net/event/56/contributions/1233/ - https://indico.dns-oarc.net/event/56/contributions/1233/attachments/1180/2539/presentation.pdf Confidential communication. No warranties or commitments unless in a signed agreement. If received in error, notify sender and delete. Unauthorized use prohibited.

And my point is that it is up to the submitter to make sure that the bug exists and is real.

I also agree that, in practice, embargoes are not costless coordination mechanisms. They impose delays, administrative overhead and a nontrivial burden on maintainers who must preserve confidentiality/track disclosure windows/manage downstream communication. Public reporting means validation, encourage duplicate detection as a signal of prevalence and improve collective defensive awareness once a responsible disclosure process has been satisfied.

Från: ROI AI <sales () roiai ca> Skickat: den 16 maj 2026 01:52 Till: oss-security <oss-security () lists openwall com> Ämne: Sv: [oss-security] Coordinated Disclosure in the LLM Age

Not sure I understand this feedback. Openstack has a lot of low hanging vulnerabilities due to legacy code. This is the central issue, not me or LLMs.

A lot of people are clamoring for sovereign cloud right now: https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnews.ycombinator.com%2Fitem%3Fid%3D48120629&data=05%7C02%7C%7C973c98c5b1bd4aa480ea08deb2e10414%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C639144876663331996%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=aM7HS448XCDx0Vl51hCEeL8pS8e%2F8SoxiOTR8KULJmk%3D&reserved=0<https://news.ycombinator.com/item?id=48120629>

An example: https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.launchpad.net%2Fswift%2F%2Bbug%2F2152384%2Fcomments%2F14&data=05%7C02%7C%7C973c98c5b1bd4aa480ea08deb2e10414%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C639144876663352635%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=qIeyDjkamPlFaLlq%2FfQRAIe5OXJjR4xX9%2BJgyHw6l68%3D&reserved=0<https://bugs.launchpad.net/swift/+bug/2152384/comments/14>

ROI AI

From: Markus Klyver <markusklyver () hotmail com> To: "oss-security () lists openwall com"<oss-security () lists openwall com> Date: Fri, 15 May 2026 08:27:57 -0700 Subject: Sv: [oss-security] Coordinated Disclosure in the LLM Age

If you want to process your all your internal thoughts and personality through a statistical probabilistic function, then you are of course absolutely entire free to do so. But please keep in mind that LLMs are also overloading open source projects with fake PRs and "fixes" that ruin the codebase (do I have to mention ffmpeg and curl?), the code quality and the lives of everyone.

If an LLM is used to find potential bugs, it is up to you to ensure it is a real bug and that you can replicate the behavior. Offloading that part to the LLM and the need for human knowledge is a loss for everyone involved. Från: Tim Shephard < mailto:tim () roiai ca > Skickat: den 12 maj 2026 03:22 Till: oss-security < mailto:oss-security () lists openwall com >; fungi < mailto:fungi () yuggoth org > Ämne: Re: [oss-security] Coordinated Disclosure in the LLM Age

Thanks for starting this discussion. I have reported a number of issues recently, including - #2149789, #2150261, #2149775, #2150316 - three of which are identified by the team as critical, and one as high. The oslo rabbit MITM is also critical, IMHO, but I agree it cannot be fixed without potentially breaking many poorly configured deployments and so must be 'Class B'. An awkward situation to be sure, but the solution is understandable.

For what it's worth my goal is not to 'mine security gold', rather I am trying to find and test potential solutions for sovereign cloud.

More to the point of the thread, I think there is also a more pressing issue adjacent to the disclosure-process question: large, long-lived projects such as OpenStack have a substantial backlog of legacy vulnerabilities and insecure patterns that are now becoming much easier to discover with LLM assistance.

That changes the risk calculation. Issues that previously required deep project knowledge, persistence, or specialized tooling may now be within reach of many more people. We should assume adversaries can use the same leverage, including for insider attacks and for chaining individually modest bugs across trust boundaries.

In that sense, this feels like a generational security event. The urgent question is not only whether embargoed details might leak through LLM use, but whether maintainers can harden exposed systems faster than attackers can rediscover and combine old weaknesses.

That argues for shorter exposure windows, more proactive hardening, and more attention to eliminating vulnerable patterns before they become practical attack paths.

Furthermore, it argues for assertive use of modern LLMs, especially for code review and vulnerability discovery. I have volunteered to help with this for the OpenStack VMT, and would be happy to do so again here.

Cheers,

Tim.

PS: LLMs helped with this email, and with more and more of the work I do. I think we need to move forward with these tools more deliberately and less fearfully. Confidential communication. No warranties or commitments unless in a signed agreement. If received in error, notify sender and delete. Unauthorized use prohibited. Confidential communication. No warranties or commitments unless in a signed agreement. If received in error, notify sender and delete. Unauthorized use prohibited.

If you want to process your all your internal thoughts and personality through a statistical probabilistic function, then you are of course absolutely entire free to do so. But please keep in mind that LLMs are also overloading open source projects with fake PRs and "fixes" that ruin the codebase (do I have to mention ffmpeg and curl?), the code quality and the lives of everyone.

If an LLM is used to find potential bugs, it is up to you to ensure it is a real bug and that you can replicate the behavior. Offloading that part to the LLM and the need for human knowledge is a loss for everyone involved. Från: Tim Shephard <tim () roiai ca> Skickat: den 12 maj 2026 03:22 Till: oss-security <oss-security () lists openwall com>; fungi <fungi () yuggoth org> Ämne: Re: [oss-security] Coordinated Disclosure in the LLM Age

Thanks for starting this discussion. I have reported a number of issues recently, including - #2149789, #2150261, #2149775, #2150316 - three of which are identified by the team as critical, and one as high. The oslo rabbit MITM is also critical, IMHO, but I agree it cannot be fixed without potentially breaking many poorly configured deployments and so must be 'Class B'. An awkward situation to be sure, but the solution is understandable.

For what it's worth my goal is not to 'mine security gold', rather I am trying to find and test potential solutions for sovereign cloud.

More to the point of the thread, I think there is also a more pressing issue adjacent to the disclosure-process question: large, long-lived projects such as OpenStack have a substantial backlog of legacy vulnerabilities and insecure patterns that are now becoming much easier to discover with LLM assistance.

That changes the risk calculation. Issues that previously required deep project knowledge, persistence, or specialized tooling may now be within reach of many more people. We should assume adversaries can use the same leverage, including for insider attacks and for chaining individually modest bugs across trust boundaries.

In that sense, this feels like a generational security event. The urgent question is not only whether embargoed details might leak through LLM use, but whether maintainers can harden exposed systems faster than attackers can rediscover and combine old weaknesses.

That argues for shorter exposure windows, more proactive hardening, and more attention to eliminating vulnerable patterns before they become practical attack paths.

Furthermore, it argues for assertive use of modern LLMs, especially for code review and vulnerability discovery. I have volunteered to help with this for the OpenStack VMT, and would be happy to do so again here.

Cheers,

Tim.

PS: LLMs helped with this email, and with more and more of the work I do. I think we need to move forward with these tools more deliberately and less fearfully. Confidential communication. No warranties or commitments unless in a signed agreement. If received in error, notify sender and delete. Unauthorized use prohibited.

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.

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

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.

OCSP stapling bypass with Apple SecTrust ========================================

Project curl Security Advisory, April 29 2026 Permalink

VULNERABILITY -------------

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.

INFO ----

This vulnerability only occurs when the curl meets two specific conditions:

Backend: It is built using an OpenSSL-based backend (including forks like BoringSSL, AWS-LC, LibreSSL, or QuicTLS).

Trust Store: It is used with Apple SecTrust, the feature that allows curl to access the native CA certificate store on Apple operating systems (macOS, iOS, iPadOS, tvOS, and watchOS).

In short, the flaw requires an OpenSSL-linked curl running on an Apple platform using the system's native certificate store.

OCSP stapling is not a widely used feature on the open web, perhaps partly because so many big name sites do not support it.

This bug is not considered a C mistake (likely to have been avoided had we not been using C).

This flaw also affects the curl command line tool.

The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2026-7009 to this issue.

CWE-295: Improper Certificate Validation

Severity: Medium

AFFECTED VERSIONS -----------------

- Affected versions: curl 8.17.0 to and including 8.19.0 - Not affected versions: curl < 8.17.0 and >= 8.20.0 - Introduced-in: https://github.com/curl/curl/commit/eefd03c572996e5d

libcurl is used by many applications, but not always advertised as such!

SOLUTION ------------

- Fixed-in: https://github.com/curl/curl/commit/51905671e07f087e28e57

RECOMMENDATIONS ---------------

We suggest you take one of the following actions immediately, in order of preference:

A - Upgrade curl and libcurl to version 8.20.0

B - Apply the patch to your version and rebuild

C - Avoid the combination OSCP stapling + Apple SecTrust

TIMELINE ---------

This issue was reported to the curl project on April 25, 2026.

curl 8.20.0 was released on April 29 2026, coordinated with the publication of this advisory.

CREDITS -------

- Reported-by: Carlos Carrillo - Patched-by: Stefan Eissing

Thanks a lot!

--

/ daniel.haxx.se || https://rock-solid.curl.dev

proxy credentials leak over redirect-to proxy =============================================

Project curl Security Advisory, April 29 2026 Permalink

VULNERABILITY -------------

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

INFO ----

The credentials are passed on base64 encoded. The receiving proxy gets no hint as for where or how the credentials are valid.

The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2026-6253 to this issue.

CWE-522: Insufficiently Protected Credentials

Severity: Medium

AFFECTED VERSIONS -----------------

This flaw has existed since curl added support for credentials in proxy strings.

- Affected versions: from curl 7.14.1 to and including 8.19.0 - Not affected versions: curl < 7.14.1 and >= 8.20.0 - Introduced-in: https://github.com/curl/curl/commit/3b60bb725913ce

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 --------

- Fixed-in: https://github.com/curl/curl/commit/188c2f166a20fa97c2325

RECOMMENDATIONS ---------------

We suggest you take one of the following actions immediately, in order of preference:

A - Upgrade to curl and libcurl 8.20.0

B - Apply the patch and rebuild libcurl

C - Avoid using proxies with credentials

TIMELINE ---------

It was reported to the curl project on April 13th 2026. We contacted distros@openwall on April 23.

libcurl 8.20.0 was released on April 29th 2026, coordinated with the publication of this advisory.

CREDITS -------

- Reported-by: Dwij Mehta - Patched-by: Daniel Stenberg

Thanks a lot!

--

/ daniel.haxx.se || https://rock-solid.curl.dev

wrong reuse of SMB connection =============================

Project curl Security Advisory, April 29 2026 Permalink

VULNERABILITY -------------

libcurl 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.

INFO ----

curl only supports SMB version 1 and no later version. SMB version 1 is considered insecure and deprecated and is therefore commonly disabled in servers. curl is scheduled to drop support for SMB later in 2026. SMB support is opt-in since 8.20.0.

In this flaw, the code simply erroneously did not consider the share name as a property to match for connection reuse.

The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2026-5773 to this issue.

CWE-488: Exposure of Data Element to Wrong Session

Severity: Low

AFFECTED VERSIONS -----------------

This flaw has existed since curl started to support SMB.

- Affected versions: from curl 7.40.0 to and including 8.19.0 - Not affected versions: curl < 7.40.0 and >= 8.20.0 - Introduced-in: https://github.com/curl/curl/commit/aec2e865f0

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.20.0 makes sure that connections using SMB never get reused.

- Fixed-in: https://github.com/curl/curl/commit/74a169575d6412d

RECOMMENDATIONS ---------------

We suggest you take one of the following actions immediately, in order of preference:

A - Upgrade to curl and libcurl 8.20.0

B - Apply the patch and rebuild libcurl

C - Avoid using SMB

TIMELINE ---------

It was reported to the curl project on April 5th 2026. We contacted distros@openwall on April 23.

libcurl 8.20.0 was released on April 29th 2026, coordinated with the publication of this advisory.

CREDITS -------

- Reported-by: Osama Hamad - Patched-by: Daniel Stenberg

Thanks a lot!

--

/ daniel.haxx.se || https://rock-solid.curl.dev

wrong reuse of HTTP Negotiate connection ========================================

Project curl Security Advisory, April 29 2026 Permalink

VULNERABILITY -------------

libcurl 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...

INFO ----

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).

The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2026-5545 to this issue.

This flaw is similar to CVE-2026-1965.

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.19.0 - Not affected versions: curl < 7.10.6 and >= 8.20.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.20.0 makes sure that connections using Negotiate are not wrongly reused.

- Fixed-in: https://github.com/curl/curl/commit/33e43985b8f3b9e6669

RECOMMENDATIONS ---------------

We suggest you take one of the following actions immediately, in order of preference:

A - Upgrade to curl and libcurl 8.20.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 April 1st 2026. We contacted distros@openwall on April 23.

libcurl 8.20.0 was released on April 29th 2026, coordinated with the publication of this advisory.

CREDITS -------

- Reported-by: Quac Tran and Ngoc Hieu - Patched-by: Stefan Eissing

Thanks a lot!

--

/ daniel.haxx.se || https://rock-solid.curl.dev

connection reuse ignores TLS requirement ========================================

Project curl Security Advisory, April 29 2026 Permalink

VULNERABILITY -------------

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 will bypass the TLS requirement and instead transmit data unencrypted.

INFO ----

This flaw requires a rather special series of events to trigger. Such a series is unlikely to be used much in the wild.

This issue only happens for transfers done using IMAP://, POP3:// or SMTP:// URL schemes. The initial transfer and the second transfer both need to be done to the same host, use the same credentials and the same URL schemes. The login and the initial transfer is done over clear-text, so the user is obviously already accepting an insecure transmission for this. This flaw still makes it worse as the second transfer is intended to be secured by TLS but is not.

The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2026-4873 to this issue.

CWE-319: Cleartext Transmission of Sensitive Information

Severity: Low

AFFECTED VERSIONS -----------------

- Affected versions: curl 7.20.0 to and including 8.19.0 - Not affected versions: curl < 7.20.0 and >= 8.20.0 - Introduced-in: https://github.com/curl/curl/commit/ec3bb8f727405642a

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.20.0 fixes this logical flaw

- Fixed-in: https://github.com/curl/curl/commit/507e7be573b0a76fca597b75

RECOMMENDATIONS ---------------

We suggest you take one of the following actions immediately, in order of preference:

A - Upgrade to curl and libcurl 8.20.0

B - Apply the patch and rebuild libcurl

C - Do not use clear-text IMAP/POP3/SMTP transfers

TIMELINE ---------

It was reported to the curl project on March 22nd 2026. We contacted distros@openwall on April 23.

libcurl 8.20.0 was released on April 29th 2026, coordinated with the publication of this advisory.

CREDITS -------

- Reported-by: Arkadi Vainbrand - Patched-by: Daniel Stenberg

Thanks a lot!

--

/ daniel.haxx.se || https://rock-solid.curl.dev

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.

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.

1. A cookie is set using the secure keyword for

netrc and default credential leak

When asked to both use a .netrc file for credentials and to follow HTTP redirects, curl could leak the password used for the first host to the followed-to host under certain circumstances.

This flaw only manifests itself if the netrc file matches the redirect target hostname, but the entry omits password or both login & password.

A curl transfer with a.com that redirects to b.com that uses a .netrc like below (with a match, but no password specified for the second host), would make curl pass on alicespassword as password even in the second transfer to the separate host b.com.

~~~ machine a.com login alice password alicespassword

default login bob ~~~

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.

The redirect implementation in curl and libcurl 5.11 through 7.19.3, when CURLOPTFOLLOWLOCATION 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 ntlmoutput 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.

Multiple stack-based buffer overflows in libcURL and cURL 7.12.1, and possibly other versions, allow remote malicious web servers to execute arbitrary code via base64 encoded replies that exceed the intended buffer lengths when decoded, which is not properly handled by (1) the Curlinputntlm function in httpntlm.c during NTLM authentication or (2) the Curlkrbkauth and krb4auth functions in krb4.c during Kerberos authentication.