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