Authorization: Negotiate sent to foreign origin

When built with wolfSSL, curl can successfully validate a pinned public key hash against a key the TLS peer does not possess. During the TLS handshake, wolfSSL validates the connection, but curl's subsequent re-parsing of the same certificate - tricked by a manipulated validity length field - extracts and matches a different embedded key, incorrectly authorizing the pinned public key.

Negotiate credentials sent to redirected origin

During an upload, curl mishandles HTTP/2 RSTSTREAM received from the server (with reason HTTP11REQUIRED or REFUSEDSTREAM) leading to a use after free of a struct Curleasy object.

Hello,

Today the curl project publishes a set of twenty-four separate vulnerabilities in association with the release of curl 8.23.0.

All vulnerabilities have their fixes mentioned in text and link to the corresponding commit that fixes the problem.

Detailed information about all vulnerabilities are available on https://curl.se/docs/security.html

One vulnerability is considered severity HIGH:

CVE-2026-92392: HTTP/2 upload Use-After-Free

The other vulnerabilities are considered severity LOW:

CVE-2026-107929: local interface connection reuse mixup CVE-2026-107928: info leak uploading over WebSockets with GnuTLS CVE-2026-94266: password leak in CURLINFOEFFECTIVEURL CVE-2026-94265: Authorization: Negotiate sent to foreign origin CVE-2026-92391: curlmimefree stack overflow by recursion CVE-2026-92390: -J no-clobber guarantee bypassed with 103 early hints CVE-2026-92389: TFTP direction confusion CVE-2026-92388: FTP wildcard write callback mixup CVE-2026-92387: never-ending loop via server response omission CVE-2026-92386: server-set cookie aborts cookie jar load CVE-2026-87866: wolfSSL public-key pinning bypass CVE-2026-87865: knownhost callback mismatches key as missing CVE-2026-87864: IMAP APPEND plus CRLF conversion command injection CVE-2026-87863: HSTS response erases persisted entries CVE-2026-87862: HSTS cache import drops longer-lived child CVE-2026-87861: cross-origin reuse of a Negotiate connection CVE-2026-86415: auto client cert connection reuse mixup CVE-2026-86414: leaking host credentials to HTTP proxy CVE-2026-86413: Negotiate credentials sent to redirected origin CVE-2026-86412: server-set cookie erases cookie jar CVE-2026-86411: FTP connection reuse inherits client-certificate CVE-2026-86410: redirect to SFTP or SCP bypasses host verification CVE-2026-86409: stale SigV4 headers sent unintended

--

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

A remote HTTP server can set a cookie that curl accepts and writes to a Netscape cookie jar but cannot reload. On the next invocation using the same path for --cookie and --cookie-jar, curl fails before connecting, then the cleanup procedure replaces the jar with an empty file, deleting cookies for unrelated domains.

A flaw in the curl command line tool's logic makes it only set SSH host verification options when interacting directly using SFTP or SCP, and not as a result of following a redirect.

An authenticated HTTPS origin can supply an HSTS max-age value that the parser accepts, but time serialization later fails to process. On 64-bit systems, extreme max-age values compute an absolute expiry within standard time integer limits that exceeds calendar time structure bounds. During cache saves, the original HSTS file is truncated before writing a temporary replacement; when serialization fails, the temporary file is deleted, leaving an empty or partial cache. Because the save error is silently ignored during cleanup, curl exits successfully despite the data loss.

-J no-clobber guarantee bypassed with 103 early hints

local interface connection reuse mixup

info leak uploading over WebSockets with GnuTLS

A Set-Cookie: header using tab (horizontal tab, ASCII code 9) instead of space (ascii code 32) immediately before the Secure attribute causes curl to store the cookie without its Secure flag. The cookie might then wrongfully be sent over plaintext HTTP on subsequent requests to the same host.

A flaw in curl’s cookie parsing logic allows a malicious HTTP server to set 'super cookies' that bypass the Public Suffix List check. This enables an attacker-controlled origin to inject cookies that curl subsequently scopes and transmits to unrelated third-party domains.

Last updated 10 July 2026

When a user invokes curl using a schemeless URL combined with --proto-default sftp (or scp), a disconnect occurs between the tool layer and libcurl. The tool layer incorrectly infers the URL scheme, which erroneously bypasses the initialization of critical SSH security options like CURLOPTSSHHOSTPUBLICKEYSHA256 and CURLOPTSSHKNOWNHOSTS. Conversely, the libcurl runtime successfully honors CURLOPTDEFAULTPROTOCOL and establishes the connection via SFTP/SCP as specified. Because the tool layer skipped the security configuration, these SSH host verification options are silently omitted, causing curl to connect to an unverified SSH remote host without throwing an error.

By default, curl automatically responds to WebSocket PING frames. Because curl lacks an upper bound on memory allocation for unacknowledged frames, a malicious server can exhaust all available memory by flooding curl with rapid, sequential PING messages.

An issue in curl’s QUIC UDP receive function allows a malicious HTTP/3 server to trigger a remote denial of service against a curl or libcurl client. Because the helper function discards zero-length UDP datagrams before counting them toward the per-call packet budget, a connected QUIC peer can continuously stream empty datagrams to indefinitely stall the client.

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.

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

A flaw was found in curl. When curl is configured to use specific proxies for different URL schemes, and a redirect occurs from a URL using a credentialed proxy to a URL using a non-credentialed proxy, curl may inadvertently send the credentials of the first proxy to the second. This can lead to the unauthorized disclosure of proxy credentials (CWE-522), potentially allowing an attacker to gain unauthorized access or information.