eventfd double close

netrc and default credential leak

gzip integer overflow

libcurl supports pinning of the server certificate public key for HTTPS transfers. Due to an omission, this check is not performed when connecting with QUIC for HTTP/3, when the TLS backend is wolfSSL. Documentation says the option works with wolfSSL, failing to specify that it does not for QUIC and HTTP/3. Since pinning makes the transfer succeed if the pin is fine, users could unwittingly connect to an impostor server without noticing.

Music Player Daemon (MPD) before version 0.24.11 contains a server-side request forgery vulnerability in CurlInputPlugin where CURLOPTFOLLOWLOCATION is set without CURLOPTREDIRPROTOCOLSSTR, allowing unauthenticated attackers to bypass the http/https scheme restriction by causing a malicious HTTP server to redirect to non-HTTP protocols such as gopher, ftp, sftp, ldap, dict, rtmp, or rtsp. Attackers can trigger this vulnerability via MPD commands that initiate URL fetches, including add, readcomments, albumart, readpicture, or load, to interact with internal or restricted network services on systems running libcurl versions prior to 7.85.0.

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

1. A cookie is set using the secure keyword for

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

cross-proxy Digest auth state leak

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.

netrc credential leak with reused proxy connection

stale custom cookie host causes cookie leak

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

Last updated 10 July 2026

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.

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.

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.

libcurl's ASN1 parser code has the GTime2str() function, used for parsing an ASN.1 Generalized Time field. If given an syntactically incorrect field, the parser might end up using -1 for the length of the time fraction, leading to a strlen() getting performed on a pointer to a heap buffer area that is not (purposely) null terminated.

This flaw most likely leads to a crash, but can also lead to heap contents getting returned to the application when CURLINFOCERTINFO (https://curl.se/libcurl/c/CURLINFOCERTINFO.html) is used.

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.

After testing original CVE-2016-5420 patch, it was discovered that libcurl built on top of NSS (Network Security Services) still incorrectly re-uses client certificates if a certificate from file is used for one TLS connection but no certificate is set for a subsequent TLS connection.

The original patch for CVE-2016-5420 has been amended to also contain the attached patch:

https://curl.haxx.se/CVE-2016-5420.patch

Last updated 10 July 2026

cross-proxy Digest auth state leak ==================================

Project curl Security Advisory, April 29 2026 Permalink

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

Successfully using libcurl to do a transfer over a specific HTTP proxy (proxyA) with Digest authentication and then changing the proxy host to a second one (proxyB) for a second transfer, reusing the same handle, makes libcurl wrongly pass on the Proxy-Authorization: header field meant for proxyA, to proxyB.

INFO ----

An evil proxyB could use this incoming request header field to impersonate the client in communicating with proxyA, as the header contains the authenticated state.

There is nothing in the request details passed to proxyB that reveal the name or the address of proxyA, which mitigates this problem.

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

This flaw does not affect the curl command line tool.

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

CWE-294: Authentication Bypass by Capture-replay

Severity: Medium

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

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

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

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

- Fixed-in: https://github.com/curl/curl/commit/c1cfdf59acbaf9504c45

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 reusing handles when changing proxies

TIMELINE ---------

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

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

CREDITS -------

- Reported-by: Muhamad Arga Reksapati - Patched-by: Daniel Stenberg

Thanks a lot!

--

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

stale custom cookie host causes cookie leak ===========================================

Project curl Security Advisory, April 29 2026 Permalink

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

Using libcurl, when a custom Host: header is first set for a HTTP request and a second request is subsequently done using the same easy handle but without the custom Host: header set, the second request would use stale information and pass on cookies meant for the first host in the second request. Leak them.

INFO ----

Setting a custom Host: header is mostly done for debugging purposes when doing clear text HTTP transfers. When using HTTPS, setting a custom hostname like this is not enough for asking for a specific virtual host since then the SNI also needs to be correct. This condition reduces the impact of this flaw, and is probably a contributing factor why no one else found it before this.

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

CWE-346: Origin Validation Error

Severity: Low

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

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

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 does not affect the curl command line tool.

SOLUTION --------

- Fixed-in: https://github.com/curl/curl/commit/3a19987a87f393d9394fe5ac

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 custom Host: headers

TIMELINE ---------

It was reported to the curl project on April 14th 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: Muhamad Arga Reksapati - Patched-by: Daniel Stenberg

Thanks a lot!

--

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

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

netrc credential leak with reused proxy connection ==================================================

Project curl Security Advisory, April 29 2026 Permalink

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

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

INFO ----

To trigger, this flaw requires that both the original URL and the redirect URL are using clear text http:// URLs, that both are performed over the same HTTP proxy and that the same connection is reused.

Similar to CVE-2024-11053

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

CWE-200: Exposure of Sensitive Information to an Unauthorized Actor

Severity: Medium

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

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

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 does not affect the curl command line tool.

SOLUTION --------

- Fixed-in: https://github.com/curl/curl/commit/b4024bf808bd558026fdc6

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 the combination netrc, HTTP and HTTP proxy

TIMELINE ---------

It was reported to the curl project on April 16th 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: Muhamad Arga Reksapati - Patched-by: Daniel Stenberg

Thanks a lot!

--

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