daniel:// stenberg://

A collection of medals

my week: https://lists.haxx.se/pipermail/daniel/2026-March/000148.html

Bug-Bounty: False, zip bombs, "just", badwords, release, new record, NTLM, SMB, 10K downloads, dependencies, nuget

curl distro meeting 2026 We are doing another curl + distro online meeting this spring in what now has become an established annual tradition. A two-hour discussion, meeting, workshop for curl developers and curl distro maintainers. 2026 curl distro meeting details The objective for these meetings is simply to make curl better in distros. To make distros do better curl. To improve curl in all and every way we think we can, together. A part of this process is to get to see the names and faces of the people involved and to _grease the machine_ to improve cross-distro collaboration on curl related topics. Anyone who feels this is a subject they care about is welcome to join. We aim for the widest possible definition of _distro_ and we don’t attempt to define the term. The 2026 version of this meeting is planned to take place in the early evening European time, morning west coast US time. With the hope that it covers a large enough amount of curl interested people. The plan is to do this on **March 26** , and all the details, planning and discussion items are kept on the dedicated wiki page for the event. Please add your own discussion topics that you want to know or talk about, and if you feel inclined, add yourself as an intended participant. Feel free to help make this invite reach the proper people. See you on March 26!

In two weeks we run the #curl distro meeting. You are invited!

https://daniel.haxx.se/blog/2026/01/28/curl-distro-meeting-2026/

chicken nuget Background: nuget.org is a Microsoft owned and run service that allows users to package software and upload it to nuget so that other users can download it. It is targeted for .Net developers but there is really no filter in what you can offer through their service. Three years ago I reported on how nuget was hosting and providing ancient, outdated and insecure curl packages. Random people download a curl tarball, build curl and then upload it to nuget, and nuget then offers those curl builds to the world – forever. To properly celebrate the three year anniversary of that blog post, I went back to nuget.org, entered _curl_ into the search bar and took a look at the results. I immediately found at least _seven_ different packages where people were providing severely outdated curl versions. The most popular of those, rmt_curl, reports that it has been downloaded almost 100,000 times over the years and is still downloaded almost 1,000 times/week the last few weeks. _It is still happening_. The packages I reported three years ago are gone, but now there is a new set of equally bad ones. No lessons learned. rmt_curl claims to provide curl 7.51.0, a version we shipped in November 2016. Right now it has 64 known vulnerabilities and we have done more than 9,000 documented bugfixes since then. No one in their right mind should ever download or use this version. Conclusion: the state of nuget is just as sad now as it was three years ago and this triggered another _someone is wrong on the internet_ moments for me. I felt I should do my duty and tell them. Again. Surely they will act this time! Surely they think of the security of their users? ## Trusting randos The entire nuget concept is setup and destined to end up like this: random users on the internet put something together, upload it to nuget and then the rest of the world downloads and uses those things – trusting that whatever the description says is accurate and well-meaning. Maybe there are some additional security scans done in the background, but I don’t see how anyone can _know_ that they don’t contain any backdoors, trojans or other nasty deliberate attacks. And whatever has been uploaded once seems to then be offered in perpetuity. ## I reported this again Like three years ago I listed a bunch of severely outdated curl packages in my report. nuget says I can email them a report, but that just sent me a bounce back saying they don’t accept email reports anymore. (Sigh, and yes I reported _that_ as a separate issue.) I was instead pointed over to the generic Microsoft security reporting page where there is not even any drop-down selection to use for “nuget” so I picked “.NET” instead when I submitted my report. ## “This is not a Microsoft problem” Almost identically to three years ago, my report was closed within less than 48 hours. It’s not a nuget problem they say. _Thank you again for submitting this report to the Microsoft Security Response Center (MSRC)._ _After careful investigation, this case has been assessed as not a vulnerability and does not meet Microsoft’s bar for immediate servicing. None of these packages are Microsoft owned, you will need to reach out directly to the owners to get patched versions published. Developers are responsible for removing their own packages or updating the dependencies._ In other words: they don’t think it’s nuget’s responsibility to keep the packages they host, secure and safe for their users. I should instead report these things individually to every outdated package provider, who if they cared, would have removed or updated these packages many years ago already. Also, that would imply a never-ending wack-a-mole game for me since people obviously keep doing this. I think I have better things to do in my life. ## Outdated efforts In the cases I reported, the packages seem to be of the kind that once had the attention and energy by someone who kept them up-to-date with the curl releases for a while and then they stopped and since then the packages on nuget has just collected dust and gone stale. Still, apparently users keep finding and downloading them, even if maybe not at terribly high numbers. Thousands of fooled users per week is thousands too many. ## How to address The uploading users are perfectly allowed to do this, legally, and nuget is perfectly allowed to host these packages as per the curl license. I don’t have a definite answer to what exactly nuget should do to address this problem once and for all, but as long as they allow packages uploaded nine years ago to still get downloaded today, it seems they are asking for this. _They contribute and aid users getting tricked into downloading and using insecure software_ , and they are indifferent to it. A rare few applications that were uploaded nine years ago might actually still be okay but those are _extremely_ rare exceptions. ## Conclusion The last time I reported this nuget problem nothing happened on the issue until I tweeted about it. This time around, a well-known Microsoft developer (who shall remain nameless here) saw my Mastodon post about this topic when mirrored over to Bluesky and pushed for the case internally – but not even that helped. The nuget management thinks this is okay. If I were into puns I would probably call them _chicken nuget_ for their unwillingness to fix this. Maybe just closing our eyes and pretending it doesn’t exist will just make it go away? Absolutely no one should use nuget.

chicken nuget

Insecure #curl packages hosted by Microsoft. They think it's fine.

https://daniel.haxx.se/blog/2026/03/12/chicken-nuget/

@luisfcorreia sure, in theory that could possible be done. But to me that would feel like giving in to them and accepting this as how it needs to be so I will not participate in that.

chicken nuget Background: nuget.org is a Microsoft owned and run service that allows users to package software and upload it to nuget so that other users can download it. It is targeted for .Net developers but there is really no filter in what you can offer through their service. Three years ago I reported on how nuget was hosting and providing ancient, outdated and insecure curl packages. Random people download a curl tarball, build curl and then upload it to nuget, and nuget then offers those curl builds to the world – forever. To properly celebrate the three year anniversary of that blog post, I went back to nuget.org, entered _curl_ into the search bar and took a look at the results. I immediately found at least _seven_ different packages where people were providing severely outdated curl versions. The most popular of those, rmt_curl, reports that it has been downloaded almost 100,000 times over the years and is still downloaded almost 1,000 times/week the last few weeks. _It is still happening_. The packages I reported three years ago are gone, but now there is a new set of equally bad ones. No lessons learned. rmt_curl claims to provide curl 7.51.0, a version we shipped in November 2016. Right now it has 64 known vulnerabilities and we have done more than 9,000 documented bugfixes since then. No one in their right mind should ever download or use this version. Conclusion: the state of nuget is just as sad now as it was three years ago and this triggered another _someone is wrong on the internet_ moments for me. I felt I should do my duty and tell them. Again. Surely they will act this time! Surely they think of the security of their users? ## Trusting randos The entire nuget concept is setup and destined to end up like this: random users on the internet put something together, upload it to nuget and then the rest of the world downloads and uses those things – trusting that whatever the description says is accurate and well-meaning. Maybe there are some additional security scans done in the background, but I don’t see how anyone can _know_ that they don’t contain any backdoors, trojans or other nasty deliberate attacks. And whatever has been uploaded once seems to then be offered in perpetuity. ## I reported this again Like three years ago I listed a bunch of severely outdated curl packages in my report. nuget says I can email them a report, but that just sent me a bounce back saying they don’t accept email reports anymore. (Sigh, and yes I reported _that_ as a separate issue.) I was instead pointed over to the generic Microsoft security reporting page where there is not even any drop-down selection to use for “nuget” so I picked “.NET” instead when I submitted my report. ## “This is not a Microsoft problem” Almost identically to three years ago, my report was closed within less than 48 hours. It’s not a nuget problem they say. _Thank you again for submitting this report to the Microsoft Security Response Center (MSRC)._ _After careful investigation, this case has been assessed as not a vulnerability and does not meet Microsoft’s bar for immediate servicing. None of these packages are Microsoft owned, you will need to reach out directly to the owners to get patched versions published. Developers are responsible for removing their own packages or updating the dependencies._ In other words: they don’t think it’s nuget’s responsibility to keep the packages they host, secure and safe for their users. I should instead report these things individually to every outdated package provider, who if they cared, would have removed or updated these packages many years ago already. Also, that would imply a never-ending wack-a-mole game for me since people obviously keep doing this. I think I have better things to do in my life. ## Outdated efforts In the cases I reported, the packages seem to be of the kind that once had the attention and energy by someone who kept them up-to-date with the curl releases for a while and then they stopped and since then the packages on nuget has just collected dust and gone stale. Still, apparently users keep finding and downloading them, even if maybe not at terribly high numbers. Thousands of fooled users per week is thousands too many. ## How to address The uploading users are perfectly allowed to do this, legally, and nuget is perfectly allowed to host these packages as per the curl license. I don’t have a definite answer to what exactly nuget should do to address this problem once and for all, but as long as they allow packages uploaded nine years ago to still get downloaded today, it seems they are asking for this. _They contribute and aid users getting tricked into downloading and using insecure software_ , and they are indifferent to it. A rare few applications that were uploaded nine years ago might actually still be okay but those are _extremely_ rare exceptions. ## Conclusion The last time I reported this nuget problem nothing happened on the issue until I tweeted about it. This time around, a well-known Microsoft developer (who shall remain nameless here) saw my Mastodon post about this topic when mirrored over to Bluesky and pushed for the case internally – but not even that helped. The nuget management thinks this is okay. If I were into puns I would probably call them _chicken nuget_ for their unwillingness to fix this. Maybe just closing our eyes and pretending it doesn’t exist will just make it go away? Absolutely no one should use nuget.

chicken nuget

Insecure #curl packages hosted by Microsoft. They think it's fine.

https://daniel.haxx.se/blog/2026/03/12/chicken-nuget/

so yeah, I would say that this is most likely satire

they claim "Zero exposure to original source" but surely all popular Open Source project has been read and parsed by every LLM in existence many times over

"Our proprietary AI robots independently recreate any open source project from scratch"

https://malus.sh/

@bsdphk a reasonable conclusion!

vulnerability age in curl

CVE-2026-3784 beat a new #curl record. This flaw existed in curl source code for 24.97 years before it was discovered.

Illustrated in the slightly hard-to-read graph below. The average age of a curl vulnerability when reported is eight years.

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

The "badwords" script we use in curl CI to detect words in documentation and source code that we want to avoid took 48 seconds to run just a few days ago.

Then it took 8 seconds after an optimization take by me.

Then 3.6 once the regexes were improved by @icing

Then 1.1 seconds with more […]

Clear the sockaddr_in6 structure before use by vlmarek · Pull Request #20885 · curl/curl On Solaris this was causing intermittent issues when the private structure member __sin6_src_id had unexpectedly some value. connect(2) would then fail with EADDRNOTAVAIL. This patch was used on So...

Welcome Vladimír Marek as #curl commit author 1452: https://github.com/curl/curl/pull/20885

curl 8.19.0 with Daniel Stenberg

https://youtu.be/5XoJTh99bPg

curlhacker - Twitch I'm Daniel Stenberg, maintainer and lead developer in the curl project. I stream curl related stuff. Release presentations, curl development and related topics.

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

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

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

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

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

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

curl would wrongly reuse an existing HTTP proxy connection doing CONNECT to a server, even if the new request uses different credentials for the HTTP proxy. The proper behavior is to create or use a separate connection […]

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

When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer performs a redirect to a second URL, curl could leak that token to the second hostname under some circumstances.

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

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

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

curl 8.19.0 Release presentation Welcome to the curlhacker stream at 10:00 CET (09:00 UTC) today March 11, 2026 for a live-streamed presentation of curl 8.19.0. The changes, the security fixes and some bugfixes. ## Numbers the 273rd release 8 changes 63 days (total: 10,712) 264 bugfixes (total: 13,640) 538 commits (total: 38,024) 0 new public libcurl function (total: 100) 0 new curl_easy_setopt() option (total: 308) 0 new curl command line option (total: 273) 77 contributors, 48 new (total: 3,619) 37 authors, 21 new (total: 1,451) 4 security fixes (total: 180) ## Security We stopped the bug-bounty but it has not stopped people from finding vulnerabilities in curl. * CVE-2026-1965: bad reuse of HTTP Negotiate connection * CVE-2026-3783: token leak with redirect and netrc * CVE-2026-3784: wrong proxy connection reuse with credentials * CVE-2026-3805: use after free in SMB connection reuse ## Changes * We stopped the bug-bounty. It’s worth repeating, even if it was no code change. * The cmake build got a `CURL_BUILD_EVERYTHING` option * Initial support for MQTTS was merged * curl now supports fractions for –limit-rate and –max-filesize * curl’s -J option now uses the redirect name as a backup * we no longer support OpenSSL-QUIC * on Windows, curl can now get built to use the native CA store by default * the minimum Windows version curl supports is now Vista (up from XP) ## Pending removals The following upcoming changes might be worth noticing. See the deprecate documentation for details. * NTLM support becomes opt-in * RTMP support is getting dropped * SMB support becomes opt-in * Support for c-ares versions before 1.16 goes away * Support for CMake 3.17 and earlier gets dropped * TLS-SRP support will be removed ## Next We plan to ship the next curl release on April 29. See you then!

Welcome to #curl 8.19.0

https://daniel.haxx.se/blog/2026/03/11/curl-8-19-0/

8 changes, 4 vulnerabilities and 264 bugs fixed. Enjoy!

(The 4 new CVEs are explained in follow-up toots.)

Code style Banned functions Complexity checks Human reviews Review bots No binary blobs No confusables Document everything Many tests Cl like crazy All the picky compiler options and -Werror Valgrind and sanitizers Static code analyzers Fuzzing (in Cl and non-stop) Cl jobs never “write back" Reproducible releases Signed releases, commits, tags code audits 2fa for all committers

Ahead of tomorrows release of four new #curl CVEs I want you to know: we do our very best to secure curl every step of the way. Security is hard.

Release OpenSSL 4.0.0-alpha1 · openssl/openssl OpenSSL 4.0.0-alpha1 is a feature release adding significant new functionality to OpenSSL. This release incorporates the following potentially significant or incompatible changes: Removed extra l...

#OpenSSL 4.0.0-alpha1 is released and current curl master builds and runs fine with it. Even doing ECH,

https://github.com/openssl/openssl/releases/tag/openssl-4.0.0-alpha1

The end of the release cycle is really the peak. When a full cycle's worth of work and efforts are combined into a fresh tarball that is sent out into the cold harsh real world with the ideal outcome that everything just keeps on working exactly like before, ideally a little better.

The night […]

Future Daniel asking a follow-up:

"when you said you ran the code and reproduced this issue, did you then "run the code" as in executed the instructions in a real CPU or did you "run the code" as in guessing what it would do based on your half-assed reading of the code?"

curl disclosed on HackerOne: Connection Reuse Ignores OAuth Bearer... ## Summary: The connection pool reuse function url_match_conn() in lib/url.c checks oauth_bearer in its credential match block — but only for protocols marked as requiring per-connection...

lesson: some people when they say they run the code, don't actually run the code...

https://hackerone.com/reports/3595753

Yesterday a person started sending me emails. Confused, incoherent emails that make no sense. Ramblings. All of them a reply to its previous. A stream of statements from someone clearly not doing well.

Now approaching 100 emails in less than 24 hours from this person.

I have not replied and I […]

A Hackerone alternative primarily targeted for Open Source projects. Yes please.

#Hackerone allows researchers a certain amount of "trial submissions" even when they have a signal value below the lowest accepted threshold for a specific program.

This effectively makes the signal requirement pointless for an individual project as the worst researcher on the platform might […]

Dependency tracking is hard curl and libcurl are written in C. Rather low level components present in many software systems. They are typically not part of any _ecosystem_ at all. They’re just a tool and a library. In lots of places on the web when you mention an Open Source project, you will also get the option to mention in which ecosystem it belongs. npm, go, rust, python etc. There are easily at least a dozen well-known and large ecosystems. curl is not part of any of those. Recently there’s been a push for PURLs (Package URLs), for example when describing your specific package in a CVE. A package URL only works when the component is part of an ecosystem. curl is not. We can’t specify curl or libcurl using a PURL. SBOM generators and related scanners use package managers to generate lists of used components _and their dependencies_. This makes these tools quite frequently just miss and ignore libcurl. It’s not listed by the package managers. It’s just in there, ready to be used. Like magic. It is similarly hard for these tools to figure out that curl in turn also depends and uses other libraries. At build-time you select which – but as we in the curl project primarily just ships tarballs with source code we cannot tell anyone what dependencies their builds have. The additional libraries libcurl itself uses are all similarly outside of the standard ecosystems. Part of the explanation for this is also be that libcurl and curl are often shipped bundled with the operating system many times, or sometimes _perceived_ to be part of the OS. Most graphs, SBOM tools and dependency trackers therefore stop at the binding or system that uses curl or libcurl, but without including curl or libcurl. The layer above so to speak. This makes it hard to figure out exactly how many components and how much software is depending on libcurl. A perfect way to illustrate the problem is to check GitHub and see how many among its vast collection of many millions of repositories that depend on curl. After all, curl is installed in some thirty billion installations, so clearly it used _a lot_. (Most of them being libcurl of course.) It lists _one_ dependency for curl. Repositories that depend on curl/curl: one. Screenshot taken on March 9, 2026 What makes this even more amusing is that it looks like this single dependent repository (Pupibent/spire) lists curl as a dependency by mistake.

Dependency tracking is hard

https://daniel.haxx.se/blog/2026/03/10/dependency-tracking-is-hard/

curlhacker - Twitch I'm Daniel Stenberg, maintainer and lead developer in the curl project. I stream curl related stuff. Release presentations, curl development and related topics.

All details about the new #curl release will be live-streamed as usual, at 09:00 UTC (10:00 CET) tomorrow.

https://www.twitch.tv/curlhacker