daniel:// stenberg://

@daniel.haxx.se

I write curl. I don't know anything. I am @bagder@mastodon.social Weekly email at https://lists.haxx.se/listinfo/daniel

HTTP Message Signatures with #curl https://daniel.haxx.se/blog/2026/07/27/http-message-signatures-with-curl/

HTTP Message Signatures with curl

The recently published RFC 9421 describes how to do _HTTP Message Signatures_ , and starting just now, curl experimentally supports them. ## Message Signatures The specification describes this as _a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message._ It is a way to verify that selected parts of the HTTP request arrives unmodified and exactly the same as when the request was created by the client. These days, it is very common that there are layers of proxies, load balancers, front-ends, CDNs, web firewalls and what not in between the client and the ultimate application. With HTTP Message Signatures, there can be assurances that the headers are components of the request end are unaltered. ## Command line This functionality comes with four new command line options to allow users to use its full power: `--httpsig-algo` allows the user to specify which algorithm to use, with _ed25519_ being used by default. The only other algorithm supported right now is _hmac-sha256_. `--httpsig-key` specifies the key to use when signing the request. `--httpsig-keyid` is the key identifier, a string that is passed on in the headers. `--httpsig-headers` details exactly which parts of the request and which headers that should be signed. If not set, it defaults to signing the method, authority, path and query. With these four new flags added to the list, curl supports 278 different command line options. ## libcurl The corresponding options of course also exist as options for curl_easy_setopt: * `CURLOPT_HTTPSIG_ALGORITHM`: signing algorithm (“ed25519” or “hmac-sha256”) * `CURLOPT_HTTPSIG_KEY`: the key to use for the signing * `CURLOPT_HTTPSIG_KEYID`: key identifier for Signature-Input * `CURLOPT_HTTPSIG_HEADERS`: a space-separated list of components to sign ## Experimental This feature is marked _experimental_. This means that it need to be explicitly enabled in the build to appear, and that we strongly discourage use of it in production as we reserve the rights to change it before it gets supported for real. We use the experimental phases as a time for people to test it, to tweak it and to learn what we should fix so that we then can support this to the end of time. We do not guarantee any backward compatibility for experimental features. Please test this feature and tell us how you experienced it! The more tests and more feedback we get, the faster we can get moved out of the experimental phase to have it present _for real_ for everyone. ## Ships This feature is already merged into git and will be part of the pending curl 8.22.0 release. As experimentally supported. ## Credits This feature was graciously brought to us by Sameeh Jubran. Top image by Antonios Ntoumas from Pixabay

daniel.haxx.se

The 7th HTTP workshop day one ended. https://daniel.haxx.se/blog/2026/07/14/workshop-basel-day-one/

Workshop Basel day one

On this hot summer’s day in Basel, Switzerland, the seventh HTTP workshop started. These events tend to work roughly the same way and the people in the room are also to large extent familiar and known since previous editions. Forty people in a meeting room, where we take turns in doing short talks on HTTP and networking topics, with the following question and discussion session. The rules for the meetings are explicitly Chatham rules, which means that everything I write about the meeting will be sufficiently fuzzy and without any company or personal names. This is not the kind of meeting that can be easily summed up in a short blog post anyway. You really should be here. Present in the room were representatives from all the world’s most prominent and used HTTP deployments: clients, browsers, CDNs, proxies and servers. I’m happy to say that there were also several first-timers. We like fresh blood. (If you think I’m being overly brief or vague about specifics in this post; that is partially on purpose but primarily because I’m a lousy note-taker and mostly write this up after a busy day that also may have involved beer.) After a round of introductions, we started. ## **Extending REST for State synchronization** REST is a set of constraints, and in this presentation it was argued that it can or maybe even should be extended to do more. A number of recent applications like Mastodon/ActivityPub, Bluesky/AT, Matrix, Nostr, IndieWeb, all currently use HTTP to do state synchronization but they all do it differently in their own unique ways. Can REST and maybe HTTP be adjusted to help this for improved interoperability? ## **Last-Modified header use over time** Looking at the Common Crawl data and comparing data over time, it was observed that responses use the Last-Modified header field more now than they did in the past, and there were great follow-up speculations on why this is so. Data also shows that a large share of these headers present dates that are almost identical to the time the requests were issued. ## **How is HTTP used in the world?** With the cc-lint tool, data was gathered on how HTTP is actually used today, proving that there is work to be done: deprecated headers are used, some headers are done wrong, and many are overly big. This indicates that there are well used both servers and clients out there that would benefit from cleanup. It probably also shows that doing HTTP correctly and all the correct headers is far from an easy task. ## **AI-bots’ use of HTTP** Another presentation showed data, this time from a well-known CDN, on the impact the existing AI scraper bots have on the Internet from their point of view. It showed that roughly half of the requests and half of the bandwidth are spent by scraper bots. A long discussion followed where the numbers were questioned as maybe the numbers look like this because a sufficiently large number of the “bad AI scrapers” appear as regular users to the classifiers. Speculations of different kinds were made. ## **The Apple HTTP stack two years later** As a follow-up from a presentation from a previous HTTP workshop we got to learn how the journey on developing their new HTTP stack has progressed and several fun adventures and lessons from that were shared with the audience. ## **Why new HTTP APIs?** A look into new HTTP API development at Apple. Some discussions and lessons learned from creating new APIs for both servers and clients. ## **Android Networking** We got an excellent walk-through of some details and internals of the Android networking stack. Emphasis was perhaps especially put on ECH and QUIC connection migration, and the final “don’t tell us when your connection closed” led to a long new discussion on how we really should fix the problem: when connection has been left idle for a long time and it is closed by the server, the client (mobile phones) don’t want to be told. This, because getting that RST and more, just wakes up the radio and more on the phone only to tell it to go back to sleep. It was theorized that if we could get rid of this unnecessary battery waste, the accumulated gain across billions of devices would make a serious dent. ## **Day one world problem solving** Several additional HTTP related problems were of course also subsequently solved as we then wandered into the city for dinner and maybe a beer. Of course yours truly returned back to his hotel room in good time to be able to write up this blog post. The best part of these workshops might be the (no pun intended) networking and discussions had completely outside of the agenda. End of day one. Two more to come,

daniel.haxx.se

Welcome to #curl 8.21.0 https://daniel.haxx.se/blog/2026/06/24/curl-8-21-0/

curl 8.21.0

## Release presentation At 09:00 UTC (11:00 CEST) today I will do a traditional live-streamed release presentation of this release over on my Twitch channel. ## Numbers the 275th release 6 changes 56 days (total: 10,817) 276 bugfixes (total: 14,187) 531 commits (total: 39,077) 0 new public libcurl function (total: 100) 0 new curl_easy_setopt() option (total: 308) 1 new curl command line option (total: 274) 102 contributors, 69 new (total: 3,731) 45 authors, 26 new (total: 1,489) 18 security fixes (total: 206) ## Security As mentioned before, the security report volume has been intense lately. We publish _eighteen_ new curl vulnerabilities this time. A new project record for a single release and for the total number of vulnerabilities published within the same calendar year. As always, we have document each vulnerability in detail and I encourage you to read up on the details. ### Severity Medium * CVE-2026-8925: SASL double-free * CVE-2026-8927: env-set cross-proxy Digest auth state leak * CVE-2026-9079: stale proxy password leak * CVE-2026-11856: cross-origin Digest auth state leak ### Severity Low * CVE-2026-8286: wrong STARTTLS connection reuse * CVE-2026-8458: wrong reuse for different services * CVE-2026-8924: trailing dot domain super cookie * CVE-2026-8926: password leak with netrc and user in URL * CVE-2026-8932: incomplete mTLS config matching in conn reuse * CVE-2026-9080: UAF after pause in socket callback * CVE-2026-9545: exposing HTTP/3 early data * CVE-2026-9546: sending old referer * CVE-2026-9547: SSH improper host validation * CVE-2026-10536: HTTP/2 stream-dependency tree UAF * CVE-2026-11352: QUIC zero-length UDP datagrams busy-loop * CVE-2026-11564: Native CA trust persist * CVE-2026-11586: WS Auto-PONG memory exhaustion * CVE-2026-12064: proto-default skips SSH verification ## Changes The huge focus on vulnerability reports during this release cycle made us merge fewer new features than we wanted, but here are the ones we still managed to get to: * curl: named globs * curl: named globs in output file name for uploads * HTTP/3 proxy CONNECT and MASQUE CONNECT-UDP support * removed HTTP/2 stream dependency tracking * removed support for CURLAUTH_DIGEST_IE * added support for SHA256 host public keys with libssh ## Bugfixes We again manage to land more than 250 separate bugfixes, and they are all detailed in the changelog. ## Pending removals Planned upcoming removals include: * local crypto implementations * NTLM * SMB * TLS-SRP support If you are concerned about any of these, speak up on the curl-library list ASAP. ## Next release Unless we messed up this one and need to do a patch release, the pending next release is scheduled to happen on September 2. This release cycle is extended by two weeks due to the summer of bliss.

daniel.haxx.se

The #curl project will not accept or otherwise handle any vulnerability reports during the month of July 2026. We call it the curl summer of bliss. https://daniel.haxx.se/blog/2026/06/15/curl-summer-of-bliss/

curl summer of bliss

**The curl project will not accept or otherwise handle any vulnerability reports during the month of July 2026**. We call it the _curl summer of bliss_. curl’s submission form on Hackerone will be paused starting July 1, 2026. Summer of bliss starts: **July 1, 2026**. 00:00 CEST Submissions resume: **August 3 2026**. 09:00 CEST The security email address will also be a dead end, as we will not process or otherwise care about security or vulnerability reports sent to us that way either. Whatever issue you find that you feel a need to report to the curl project during this month has to wait. curl’s Hackerone form opens for submissions again on Monday August 3. We do not accept vulnerability reports over email in general, and this fact remains during and after our vacation. ## Vacation for real The curl maintainers will use this time of less pressure to take in some extra air and to enjoy the summer. Maybe stroll outside a bit more. Breath. Some of us may spend some of this time to see other places. We may get some extra time to spend on fixing bugs or working on new code. Fun stuff! ## Side-effects As a direct side-effect of this summer of bliss, to allow us some more time to handle the issues that might have piled up for us in early August, **we also push the release date** of 8.22.0 two weeks into the future. Now scheduled to happen on September 2, 2026. ## Vulnerability rate As previously mentioned, we have been under a huge pressure for the last four months or so. Now we need some rest. We do not expect this deluge to be over. ## GitHub curl’s issue and pull-request trackers on GitHub remain open and active like normal. ## You too? If you and your Open Source projects also want to participate in the summer of bliss 2026: just do it and let us know! I would of course encourage you to do so. To take care of yourself as a top priority. ## The bad guys won’t rest Probably not. But we will. ## But what if there is an emergency Then we get to read about it in August. Or you get a support contract and we get to read about it earlier. ## Contracts excluded Everyone with a paid support contracts will of course still get full and appropriate service even during this period. Daniel, in a relaxed state. ## Credits The ice cream image was made by fotografierende from Pixabay

daniel.haxx.se

A human in control. In #curl development. https://daniel.haxx.se/blog/2026/06/10/a-human-in-control/

A human in control

There seems to be a fair amount of people in either extremes in the current AI landscape. At one side we see the “vibe coders” who use agents and allow them to merge code without any person even looking at the source, while on the other side of the field there are people who are against everything and anything even remotely associated with AI. My personal stance is somewhere in between, as I suppose shouldn’t be too surprising to readers of this blog. ## A work of love and pride The core team behind curl, and that is more people than just me, consists of individuals to whom code quality and source code excellence is important. We do software development because it is a craft we love and we are proud of what we have accomplished this far. We do not hand over our responsibilities to any machines. _We stand for ever bit of code we merge – as humans._ ## AIs do mistakes Blindly accepting code written by AI means that you merge a certain amount of errors, but this is certainly true for human written code as well, so this is not in itself special. Some data suggests that AI generated code might even contain more mistakes than the human versions. We invented test cases and code review a long time ago as a means to help us combat and reduce mistakes to get merged. The particular way code was written does not take away the benefits from code review and getting additional checks and eyes on pending changes. A good code review helps spotting mistakes, omissions or slip-ups. It also helps reinforce the architecture and established design choices. This is true however the code was created. This far, code reviews done by automatic AI bots and the likes have not yet managed to replace the humans. They are simply not good enough. Human reviews are much better. They catch other things and they help make sure proposed changes stay on track. Not to mention how I want to know how curl works, even if I don’t keep 100% intimate knowledge of every single angle and corner, I know most of it. I think it helps me make better decisions, debug better, help users better and keep the architecture sound. Getting the initial code written is not the big deal. For curl, maintaining and polishing the landed code _through decades_ is the real task. _Everything we merge in curl is determined fine and fitting by humans._ ## Humans do mistakes In all living software projects we get bugs reported and we fix them. We do new releases and continue to iterate. We have done this since software was invented and we still do, as humans are quite fallible and easily make mistakes. We try to reduce the error density and frequency by adding tests and by adding more human eyes on the code before we green-light it. It helps, but is not perfect. To help us do better code we invent, introduce and enforce a wide variety of different tools. With tools that look at code and identify problems in the early stages, they help avoid landing bad code in the first place. They make us do better code. They reduce the bug frequency. Some of the best tools for detecting coding mistakes today use AI. These tools might work on existing source code in a git repository or they might look at proposed changes in pull-requests. Above I mentioned that human code reviews are better; but the opposite is also true. In a somewhat complicated change request, it is now common that after the humans can’t spot any more problems, the AI PR review bots can still find an issue or two to remark on. Sure, sometimes they are wrong and then the comment is easily dismissed, but more often than not the findings they point out are actually something worth addressing before merge. _curl is developed and driven by humans, assisted by tools._ ## Communication is for humans Open Source is about sharing code and is a development model where we do things in the open. The _communication_ part of this model is key. Share your ideas, your visions, your problems or maybe just your ideas for what to do this afternoon. Express what you want or what the problem is, and the team can respond and we can work together on fixing and improving whatever needs to be done. Effective communication, a condition for good Open Source, implies _human-to-human_ interaction. Inserting a large AI generated tone-deaf large wall-of-text into such a flow _can_ still work, but only in the same way humans can learn to work with difficult individuals as well. It is not ideal and it is not a smooth way of working. It introduces sand in the machine. Don’t do that. It is rude. _Effective Open Source work means we communicate as humans, even if parts of the work and the code is made with the help of AI._ ## The combination Humans and machines excel at different things. We can complement each other in software development. Everyone is free to act to their own will, but in the curl project we don’t hand over responsibility to machines. We stand for our product. We make it as good as we possibly can; using all the tools that are available to us. I claim that in order to do this, humans need to remain in control.

daniel.haxx.se

#Mythos finds a #curl vulnerability yes, as in singular one. https://daniel.haxx.se/blog/2026/05/11/mythos-finds-a-curl-vulnerability/

Mythos finds a curl vulnerability

yes, as in singular _one_. Back in April 2026 Anthropic caused a lot of media noise when they concluded that their new AI model _Mythos_ is _dangerously good_ at finding security flaws in source code. Apparently Mythos was so good at this that Anthropic would not release this model to the public yet but instead trickle it out to a selected few companies for a while to allow a few good ones(?) to get a head start and fix the most pressing problems first, before the general populace would get their hands on it. The whole world seemed to lose its marbles. Is this the end of the world as we know it? An amazingly successful marketing stunt for sure. ## My (non-) access Part of the deal with _project Glasswing _was that Anthropic also offered access to their latest AI model to “Open Source projects” via Linux Foundation. Linux Foundation let their project Alpha Omega handle this part, and I was contacted by their representatives. As lead developer of curl I was offered access to the magic model and I graciously accepted the offer. Sure, I’d like to see what it can find in curl. I signed the contract for getting access, but then nothing happened. Weeks went past and I was told there was a hiccup somewhere and access was delayed. Eventually, I was instead offered that someone else, who has access to the model, could run a scan and analysis on curl for me using Mythos and send me a report. To me, the distinction isn’t that important. It’s not that I would have a lot of time to explore lots of different prompts and doing deep dive adventures anyway. Getting the tool to generate a first proper scan and analysis would be great, whoever did it. I happily accepted this offer. (I am purposely leaving out the identity of the individual(s) involved in getting the curl analysis done as it is not the point of this blog post.) ## AI scans of curl Before this first Mythos report, we had already scanned curl with several different very capable AI powered tools (I mean _in addition to_ running a number of “normal” static code analyzers all the time, using the pickiest compiler options and doing fuzzing on it for years etc). Primarily AISLE, Zeropath and OpenAI’s Codex Security have been used to scrutinize the code with AI. These tools and the analyses they have done have triggered somewhere between _two and three hundred_ bugfixes merged in curl through-out the recent 8-10 months or so. A bunch of the findings these AI tools reported were confirmed vulnerabilities and have been published as CVEs. Probably a dozen or more. Nowadays we also use tools like GitHub’s Copilot and Augment code to review pull requests, and their remarks and complaints help us to land better code and avoid merging new bugs. I mean, we still merge bugs of course but the PR review bots regularly highlight issues that we fix: our merges would be worse without them. The AI reviews are used _in addition_ to the human reviews. They help us, they don’t replace us. We also see a high volume of high quality security reports flooding in: security researchers now use AI extensively and effectively. Security is a _top_ _priority_ for us in the curl project. We follow every guideline and we do software engineering properly, to reduce the number of flaws in code. Scanning for flaws is just one of many steps to keep this ship safe. You need to search long and hard to find another software project that makes as much or goes further than curl, for software security. Steps involved in keeping curl secure ## May 6, 2026 It was with great anticipation we received the first source code analysis report generated with Mythos. Another chance for us to find areas to improve and bugs to fix. To make an even better curl. This initial scan was made on curl’s git repository and its master branch of a certain recent commit. It counted 178K lines of code analyzed in the src/ and lib/ subdirectories. The analysis details several different approaches and methods it has performed the search, and how it has focused on trying to find which flaws. A fun note in the top of the report says: > curl is one of the most fuzzed and audited C codebases in existence (OSS-Fuzz, Coverity, CodeQL, multiple paid audits). Finding anything in the hot paths (HTTP/1, TLS, URL parsing core) is unlikely. … and it correctly found no problems in those areas. Completely unscientific poll on Mastodon about people’s expectations for Mythos scanning curl ## The size of curl curl is currently 176,000 lines of C code when we exclude blank lines. The source code consists of 660,000 words, which is 12% more words than the entire English edition of the novel War and Piece. On average, every single production source code line of curl has been written (and then rewritten) 4.14 times. We have polished on this. Right now, the existing production code in git master that still remains, has been authored by 573 separate individuals. Over time, a total of 1,465 individuals have so far had their proposed changes merged into curl’s git repository. We have published 188 CVEs for curl up until now. curl is installed in over _twenty million instances_. It runs on over _110 operating systems_ and _28 CPU architectures_. It runs in every smart phone, tablet, car, TV, game console and server on earth. ## Five findings became one The report concluded it found **five** “Confirmed security vulnerabilities”. I think using the term _confirmed_ is a little amusing when the AI says it confidently by itself. Yes, the AI thinks they are confirmed, but the curl security team has a slightly different take. Five issues felt like nothing as we had expected an extensive list. Once my curl security team fellows and I had poked on the this short list for a number of hours and dug into the details, we had trimmed the list down and were left with _one_ confirmed vulnerability. The other four were three false positives (they highlighted shortcomings that are documented in API documentation) and the fourth we deemed “just a bug”. The single confirmed vulnerability is going to end up a _severity low_ CVE planned to get published in sync with our pending next curl release 8.21.0 in late June. The flaw is not going to make anyone grasp for breath. All details of that vulnerability will of course not get public before then, so you need to hold out for details on that. The Mythos report on curl also contained a number of spotted bugs that it concluded were not vulnerabilities, much like any new code analyzer does when you run it on hundreds of thousands of lines of code. All the bugs in the report are being investigated and one bye one we are fixing those that we agree with. All in all about twenty bugs that are described and explained very nicely. Barely any false positives, so I presume they have had a rather high threshold for certainty. curl is certainly getting better thanks to this report, but counted by the volume of issues found, all the previous AI tools we have used have resulted in larger bugfix amounts. This is only natural of course since the first tools we ran had many more and easier bugs to find. As we have fixed issues along the way, finding new ones are slowly becoming harder. Additionally, a bug can be small or big so it’s not always fair to just compare numbers ## Not particularly “dangerous” My personal conclusion can however not end up with anything else than that the big hype around this model so far was primarily marketing. I see no evidence that this setup finds issues to any particular higher or more advanced degree than the other tools have done before Mythos. Maybe this model is a little bit better, but even if it is, it is not better to a degree that seems to make a significant dent in code analyzing. This is just _one_ source code repository and maybe it is much better on other things. I can only tell and comment on what it found here. ## Still very good But allow me to highlight and reiterate what I have said before: AI powered code analyzers are _significantly_ better at finding security flaws and mistakes in source code than any traditional code analyzers did in the past. All modern AI models are good at this now. Anyone with time and some experimental spirits can find security problems now. The high quality chaos is real. Any project that has not scanned their source code with AI powered tooling will likely find huge number of flaws, bugs and possible vulnerabilities with this new generation of tools. Mythos will, and so will many of the others. Not using AI code analyzers in your project means that you leave adversaries and attackers time and opportunity to find and exploit the flaws you don’t find. ## How AI analyzers differ * They can spot when the comment says something about the code and then conclude that the code does not work as the comment says. * It can check code for platforms and configurations we otherwise cannot run analyzers for * It “knows” details about 3rd party libraries and their APIs so it can detect abuse or bad assumptions. * It “knows” details about protocols curl implements and can question details in the code that seem to violate or contract protocol specifications * They are typically good at summarizing and explaining the flaw, something which can be rather tedious and difficult with old style analyzers. * They can often generate and offer a patch for its found issue (even if the patch usually is not a 100% fix). ## More details from the report **Zero memory-safety vulnerabilities found.** Methodology note: this review is hand-driven analysis using LLM subagents for parallel file reads, with every candidate finding re-verified by direct source inspection in the main session before being recorded. The CVE to variant-hunt mapping was built from curl’s own vuln.json. No automated SAST tooling was used. This outcome is consistent with curl’s status as one of the most heavily fuzzed and audited C codebases. The defensive infrastructure (capped dynbufs everywhere, `curlx_str_number` with explicit max on every numeric parse, `curlx_memdup0` overflow guard, CURL_PRINTF format-string enforcement, per-protocol response-size caps, pingpong 64KB line cap) systematically closes the bug classes that would normally be productive in a codebase this size. Coverage now includes: all minor protocols, all file parsers, all TLS backends’ verify paths, http/1/2/3, ftp full depth, mprintf, x509asn1, doh, all auth mechanisms, content encoding, connection reuse, session cache, CLI tool, platform-specific code, and CI/build supply chain. ## AI finds existing kinds of errors It should be noted that the AI tools find the usual and established kind of errors we already know about. It just finds new instances of them. We have not seen any AI so far report a vulnerability that would somehow be of a novel kind or something totally new. They do not reinvent the field in that way, but they do dig up more issues than any other tools did before. ## More to find These were absolutely not the last bugs to find or report. Just while I was writing the drafts for this blog post we have received more reports from security researchers about suspected problems. The AI tools will improve further and the researchers can find new and different ways to prompt the existing AIs to make them find more. We have not reached the end of this yet. I hope we can keep getting more curl scans done with Mythos and other AIs, over and over until they truly stop finding new problems. ## Credits Thanks to Anthropic and Alpha Omega for providing the model, the tools and doing the scan for us. Thanks also to the individual who did the scan for us. Much appreciated! Top image by Jin Kim from Pixabay Thanks for flying curl. It’s never dull.

daniel.haxx.se

I feel honored to present to you: #curl 8.20.0 https://daniel.haxx.se/blog/2026/04/29/curl-8-20-0/

curl 8.20.0

You always find the new curl releases on the curl site! ## Release presentation At 10:00 CEST (08:00 UTC) I will do my transitional live-streamed video presentation of curl 8.20.0 on my twitch channel. ## Numbers the 274th release 8 changes 49 days (total: 10,761) 282 bugfixes (total: 13,922) 521 commits (total: 38,545) 0 new public libcurl function (total: 100) 0 new curl_easy_setopt() option (total: 308) 0 new curl command line option (total: 273) 73 contributors, 45 new (total: 3,664) 28 authors, 12 new (total: 1,463) 8 security fixes (total: 188) ## Security As mentioned elsewhere, the security reporting volume has been intense lately. We publish _seven_ new curl vulnerabilities this time. * CVE-2026-7168: cross-proxy Digest auth state leak * CVE-2026-7009: OCSP stapling bypass with Apple SecTrust * CVE-2026-6429: netrc credential leak with reused proxy connection * CVE-2026-6276: stale custom cookie host causes cookie leak * CVE-2026-6253: proxy credentials leak over redirect-to proxy * CVE-2026-5773: wrong reuse of SMB connection * CVE-2026-5545: wrong reuse of HTTP Negotiate connection * CVE-2026-4873: connection reuse ignores TLS requirement ## Changes * now uses a thread pool and queue for resolving * NTLM is disabled by default * dropped support for CMake 3.17 and older * dropped support for < c-ares 1.16.0 * SMB is disabled by default * added CURLMNWC_CLEAR_ALL for all network changes * dropped RTMP support ## Bugfixes The official count says over 260 bugfixes were merged in this 49 day cycle. See the changelog for all the details. ## Pending Removals Planned upcoming removals include: * local crypto implementations * NTLM * SMB * TLS-SRP support If you are concerned about any of these, speak up on the curl-library ASAP. ## Next release Unless we messed up this one and need to do a patch release, the pending next release is scheduled to happen on June 24.

daniel.haxx.se

High-Quality chaos. This is where we're at right now, security reporting wise. https://daniel.haxx.se/blog/2026/04/22/high-quality-chaos/

High-Quality Chaos

As I have been preparing slides for my coming talk at foss-north on April 28, 2026 I figured I could take the opportunity and share a glimpse of the current reality here on my blog. The _high quality chaos_ era, as I call it. ## No more AI slop I complained and I complained about the high frequency junk submissions to the curl bug-bounty that grew really intense during 2025 and early 2026. To the degree that we shut it down completely on February 1st this year. At the time we speculated if that would be sufficient or if the flood would go on. Now we know. ## Higher volume, higher quality In March 2026, the curl project went back to Hackerone again once we had figured out that GitHub was not good enough. From that day, the nature of the security report submissions have changed. The slop situation is not a problem anymore. **AI slop rate** The report frequency is higher than ever. Recently it’s been about double the rate we had through 2025, which already was more than double from previous years. **Number of hours between security reports** The quality is higher. The rate of confirmed vulnerabilities is back to and even surpassing the 2024 pre-AI level, meaning somewhere in the 15-16% range. **Confirmed vulnerability rate** In addition to that, the share of reports that identify a bug, meaning that they aren’t vulnerabilities but still some kind of problem, is significantly higher than before. **Share of reports that were bugs, not vulnerabilities** ## Everything is AI now Almost every security report now uses AI to various degrees. You can tell by the way they are worded, how the report is phrased and also by the fact that they now easily get very detailed duplicates in ways that can’t be done had they been written by humans. The difference now compared to before however, is that they are mostly very high quality. The reporters rarely mention exactly which AI tool or model they used (and really, we don’t care), but the evidence is strong that they used such help. ## We are not unique I did a quick unscientific poll on Mastodon to see if other Open Source projects see the same trends and man, do they! Friends from the following projects confirmed that they too see this trend. Of course the exact numbers and volumes vary, but it shows its not unique to any specific project. Apache httpd, BIND, curl, Django, Elasticsearch Python client, Firefox, git, glibc, GnuTLS, GStreamer, Haproxy, Immich, libssh, libtiff, Linux kernel, OpenLDAP, PowerDNS, python, Prometheus, Ruby, Sequoia PGP, strongSwan, Temporal, Unbound, urllib3, Vikunja, Wireshark, wolfSSL, … I bet this list of project is just a random selection that just happened to see my question. You will find many more experiencing and confirming this reality view. ## An explosion When we ship curl 8.20.0 in the middle of next week – end of April 2026, we expect to announce at least six new vulnerabilities. Assuming that the trend keeps up for at least the rest of the year, and I think that is a fair assumption, we are looking at an estimated explosion and a record amount of CVEs to be published by the curl project this year. We might publish closer to 50 curl vulnerabilities. **Number of published vulnerabilities** Given this universal trend, I cannot see how this pattern can not also be spotted and expected to happen in many other projects as well. ## Where does it end? The tools are still improving. We keep adding flaws when we do bugfixes and add new features. Someone has suggested it might work as with fuzzing, that we will see a plateau within a few years. I suppose we just have to see how it goes. This avalanche is going to make maintainer overload even worse. Some projects will have a hard time to handle this kind of backlog expansion without any added maintainers to help. It is probably a good time for the bad guys who can easily find this many problems themselves by just using the same tools, before all the projects get time, manpower and energy to fix them. Then everyone needs to update to the released versions, which we know is likely to take an even longer time. We are up for a bumpy ride.

daniel.haxx.se

chicken nuget Insecure #curl packages hosted by Microsoft. They think it's fine. https://daniel.haxx.se/blog/2026/03/12/chicken-nuget/

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.

daniel.haxx.se

the Prize for Excellence in Open Source 2026 is handed out tonight in Brussels by the European Open Source Academy, and it is my honor as president to hand over this award to a truly worthy winner. I am sure you will agree with me once you learn who it is. Tonight.

The end of the #curl bug-bounty https://daniel.haxx.se/blog/2026/01/26/the-end-of-the-curl-bug-bounty/

The end of the curl bug-bounty

tldr: an attempt to reduce the _terror reporting_. **There is no longer a curl bug-bounty program.** It officially stops on January 31, 2026. After having had a few half-baked previous takes, in April 2019 we kicked off the first real curl bug-bounty with the help of Hackerone, and while it stumbled a bit at first it has been quite successful I think. We attracted skilled researchers who reported plenty of actual vulnerabilities for which we paid fine monetary rewards. We have certainly made curl better as a direct result of this: **87 confirmed vulnerabilities and over 100,000 USD** paid as rewards to researchers. I’m quite happy and proud of this accomplishment. I would like to especially highlight the awesome Internet Bug Bounty project, which has paid the bounties for us for many years. We could not have done this without them. Also of course Hackerone, who has graciously hosted us and been our partner through these years. Thanks! ## How we got here Looking back, I think we can say that the downfall of the bug-bounty program started slowly in the second half of 2024 but accelerated badly in 2025. We saw an explosion in AI slop reports combined with a lower quality even in the reports that were not obvious slop – presumably because they too were actually misled by AI but with that fact just hidden better. Maybe the first five years made it possible for researchers to find and report the low hanging fruit. Previous years we have had a rate of somewhere north of 15% of the submissions ending up confirmed vulnerabilities. Starting 2025, the confirmed-rate plummeted to below 5%. Not even one in twenty was _real_. The never-ending slop submissions take a serious mental toll to manage and sometimes also a long time to debunk. Time and energy that is completely wasted while also hampering our will to live. I have also started to get the feeling that a lot of the security reporters submit reports with a _bad faith attitude._ These “helpers” try too hard to twist whatever they find into something horribly bad and a critical vulnerability, but they rarely actively contribute to actually _improve_ curl. They can go to extreme efforts to argue and insist on their specific current finding, but not to write a fix or work with the team on improving curl long-term etc. I don’t think we need more of that. There are these three bad trends combined that makes us take this step: the mind-numbing AI slop, humans doing worse than ever and the apparent will to poke holes rather than to help. ## Actions In an attempt to do something about the sorry state of curl security reports, this is what we do: * We no longer offer any monetary rewards for security reports – no matter which severity. In an attempt to remove the incentives for submitting made up lies. * We stop using Hackerone as the recommended channel to report security problems. To make the change immediately obvious and because without a bug-bounty program we don’t need it. * We refer everyone to submit suspected curl security problems on GitHub using their _Private vulnerability reporting_ feature. * We continue to immediately _ban and publicly_ _ridicule_ everyone who submits AI slop to the project. ## Maintain curl security We believe that we can maintain and continue to evolve curl security in spite of this change. Maybe even improve thanks to this, as hopefully this step helps prevent more people pouring sand into the machine. Ideally we reduce the amount of wasted time and effort. I believe the best and our most valued security reporters still will tell us when they find security vulnerabilities. ## Instead If you suspect a security problem in curl going forward, we advise you to head over to GitHub and submit them there. Alternatively, you send an email with the full report to `security @ curl.se`. In both cases, the report is received and handled privately by the curl security team. But with _no monetary reward offered_. ## Leaving Hackerone Hackerone was good to us and they have graciously allowed us to run our program on their platform for free for many years. We thank them for that service. As we now drop the rewards, we feel it makes a clear cut and displays a clearer message to everyone involved by also moving away from Hackerone as a platform for vulnerability reporting. It makes the change more visible. ## Future disclosures It is probably going to be harder for us to publicly disclose every incoming security report in the same way we have done it on Hackerone for the last year. We need to work out something to make sure that we can keep doing it at least imperfectly, because I believe in the goodness of such transparency. ## We stay on GitHub Let me emphasize that this change does not impact our presence and mode of operation with the curl repository and its hosting on GitHub. We hear about projects having problems with low-quality AI slop submissions on GitHub as well, in the form of issues and pull-requests, but for curl we have not (yet) seen this – and frankly I don’t think switching to a GitHub alternative saves us from that. ## Other projects do better Compared to others, we seem to be affected by the sloppy security reports to a higher degree than the average Open Source project. With the help of Hackerone, we got numbers of how the curl bug-bounty has compared with other programs over the last year. It turns out curl’s program has seen more volume and noise than other public open source bug bounty programs in the same cohort. Over the past four quarters, curl’s inbound report volume has risen sharply, while other bounty-paying open source programs in the cohort, such as Ruby, Node, and Rails, have not seen a meaningful increase and have remained mostly flat or declined slightly. In the chart, the pink line represents curl’s report volume, and the gray line reflects the broader cohort. Inbound Report Volume on Hackerone: curl compared to OSS peers We suspect the idea of getting money for it is a big part of the explanation. It brings in real reports, but makes it too easy to be annoying with little to no penalty to the user. The reputation system and available program settings were not sufficient for us to prevent sand from getting into the machine. The exact reason why we suffer more of this abuse than others remains a subject for further speculation and research. ## If the volume keeps up There is a non-zero risk that our guesses are wrong and that the volume and security report frequency will keep up even after these changes go into effect. If that happens, we will deal with it then and take further appropriate steps. I prefer not to overdo things or _overplan_ already now for something that ideally does not happen. ## We won’t charge People keep suggesting that one way to deal with the report tsunami is to _charge_ security researchers a small amount of money for the privilege of submitting a vulnerability report to us. A _curl reporters security club_ with an entrance fee. I think that is a less good solution than just dropping the bounty. Some of the reasons include: * Charging people money in an International context is complicated and a maintenance burden. * Dealing with charge-backs, returns and other complaints and friction add work. * It would limit who could or would submit issues. Even some who actually find legitimate issues. Maybe we need to do this later anyway, but we stay away from it for now. ## Pull requests are less of a problem We have seen other projects and repositories see similar AI-induced problems for pull requests, but this has not been a problem for the curl project. I believe for PRs we have better much means to sort out the weed with automatic means, since we have tools, tests and scanners to verify such contributions. We don’t need to waste any human time on pull requests until the quality is good enough to get green check-marks from 200 CI jobs. ## Related I will do a talk at FOSDEM 2026 titled Open Source Security in spite of AI that of course will touch on this subject. ## Future We never say never. This is now and we might have reasons to reconsider and make a different decision in the future. If we do, we will let you know. These changes are applied now with the hope that they will have a positive effect for the project and its maintainers. If that turns out to not be the outcome, we will of course continue and apply further changes later. ## Media Since I created the pull request for updating the bug-bounty information for curl on January 14, almost two weeks before we merged it, various media picked up the news and published articles. Long before I posted this blog post. * The Register: Curl shutters bug bounty program to remove incentive for submitting AI slop * Elektroniktidningen: cURL removes bug bounties * Heise online: curl: Projekt beendet Bug-Bounty-Programm * Neowin: Beloved tool, cURL is shutting down its bug bounty over AI slop reports * Golem: Curl-Entwickler dreht dem “KI-Schrott” den Geldhahn zu * Linux Easy: cURL chiude il programma bug bounty: troppi report generati dall’AI * Bleeping Computer: Curl ending bug bounty program after flood of AI slop reports * The New Stack: Drowning in AI slop, cURL ends bug bounties * Ars Technica: Overrun with AI slop, cURL scraps bug bounties to ensure “intact mental health” * PressMind Labs: cURL ko?czy program bug bounty – czy to koniec jako?ci zg?osze?? * Socket: curl Shuts Down Bug Bounty Program After Flood of AI Slop Reports Also discussed (indirectly) on Hacker News.

daniel.haxx.se

I am very proud to share that I have been awarded the IP Prize by the Swedish Network Users Society (SNUS). The motivation covers over 30 years of my work with Open Standards, Open Networks and now cyber security. From PC/TCP to Asterisk and Kamailio to the current work. Thank you SNUS!

Bild

#curl 8.18.0 has been released https://daniel.haxx.se/blog/2026/01/07/curl-8-18-0/

curl 8.18.0

Download curl from curl.se! ## Release presentation On January 7 2026, at 10:00 CET (09:00 UTC), there is a live-streamed release presentation of curl 8.18.0 done on twitch. The YouTube recording will be made available afterwards. ## Numbers the 272nd release 5 changes 63 days (total: 10,155) 391 bugfixes (total: 13,376) 758 commits (total: 37,486) 0 new public libcurl function (total: 100) 0 new curl_easy_setopt() option (total: 308) 0 new curl command line option (total: 273) 69 contributors, 36 new (total: 3,571) 37 authors, 14 new (total: 1,430) 6 security fixes (total: 176) ## Security This time there is no less than _six_ separate vulnerabilities announced. * CVE-2025-13034: skipping pinning check for HTTP/3 with GnuTLS * CVE-2025-14017: broken TLS options for threaded LDAPS * CVE-2025-14524: bearer token leak on cross-protocol redirect * CVE-2025-14819: OpenSSL partial chain store policy bypass * CVE-2025-15079: libssh global knownhost override * CVE-2025-15224: libssh key passphrase bypass without agent set ## Changes There are a few this time, mostly around dropping support for various dependencies: * drop support for VS2008 (Windows) * drop Windows CE / CeGCC support * drop support for GnuTLS < 3.6.5 * gnutls: implement CURLOPT_CAINFO_BLOB * openssl: bump minimum OpenSSL version to 3.0.0 ## Bugfixes See the release presentation video for a walk-through of some of the most important/interesting fixes done for this release, or go check out the full list in the changelog.

daniel.haxx.se

a #curl 2025 review https://daniel.haxx.se/blog/2025/12/23/a-curl-2025-review/

A curl 2025 review

Let’s take a look back and remember some of what this year brought. ## commits At more than 3,400 commits we did 40% more commits in curl this year than any single previous year! Since at some point during 2025, all the other authors in the project have now added more lines in total to the curl repository than I have. Meaning that out of all the lines ever added in the curl repository, I have now added less than half. More than 150 individuals authored commits we merged during the year. Almost one hundred of them were first-timers. Thirteen authors wrote ten or more commits. Viktor Szakats did the most number of commits per month for almost all months in 2025. Stefan Eissing has now done the latest commit for 29% of the product source code lines – where my share is 36%. About 598 authors have their added contributions still “surviving” in the product code. This is down from 635 at end of last year. ## tests We have 232 more tests at the end of this year compared to last December (now at 2179 separate test cases), and for the first time ever we have more than twelve test cases per thousand lines of product source code. (Sure, counting test cases is rather pointless and weird since a single test can be small or big, simple or complex etc, but that’s the only count we have for this.) ## releases The eight releases we did through the year is a fairly average amount: * 8.12.0 * 8.12.1 * 8.13.0 * 8.14.0 * 8.14.1 * 8.15.0 * 8.16.0 * 8.17.0 No major revolution happened this year in terms of big features or changes. We reduced source code complexity a lot. We have stopped using some more functions we deem were often the reasons for errors or confusion. We have increased performance. We have reduced numbed of used allocations. We added experimental support for HTTPS-RR, the DNS record. The bugfix frequency rate beat new records towards the end of the year as nearly 450 bugfixes shipped in curl 8.17.0. This year we started doing _release candidates_. For every release we upload a series of candidates before the actual release so that people can help us and test what is almost the finished version. This helps us detect and fix regressions before the final release rather than immediately after. ## Command line options We end the year with 6 more curl command line options than we had last new year’s eve; now at 273 in total. 8.17.0| –knownhosts ---|--- 8.16.0| –out-null –parallel-max-host –follow 8.14.0| –sigalgs 8.13.0| –upload-flags 8.12.0| –ssl-sessions ## man page The curl man page continued to grow; now more than 500 lines longer since last year (7090 lines), which means that even when counted number of man page lines per command line option it grew from 24.7 to 26. ## Lines of code libcurl grew with a mere 100 lines of code over the year while the command line tool got 1,150 new lines. libcurl is now a little over 149,000 lines. The command line tool has 25,800 lines. Most of the commits clearly went into improving the products rather than expanding them. See also the _dropped support_ section below. ## QUIC This year OpenSSL finally introduced and shipped an API that allows QUIC stacks to use vanilla OpenSSL, starting with version 3.5. As a direct result of this, the use of the OpenSSL QUIC stack has been marked as deprecated in curl and is queued for removal early next year. As we also removed msh3 support during 2025, we are looking towards a 2026 with supporting only two QUIC and HTTP/3 backends in curl. ## Security This year the number of AI slop security reports for curl really exploded. The curl security team has gotten a lot of extra load because of this. We have been mentioned in media a lot during the year because of this. The reports not evidently made with AI help have also gotten significantly worse quality wise while the total volume has increased – a lot. Also adding to our collective load. We published nine curl CVEs during 2025, all at severity low or medium. ## AI improvements A new breed of AI-powered high quality code analyzers, primarily ZeroPath and Aisle Research, started pouring in bug reports to us with potential defects. We have fixed several hundred bugs as a direct result of those reports – so far. This is in addition to the regular set of code analyzers we run against the code and for which we of course also fix the defects they report. ## Web traffic At the end of the year 2025 we see 79 TB of data getting transferred monthly from curl.se. This is up from 58 TB (+36%) for the exact same period last year. We don’t have logs or analysis so we don’t know for sure what all this traffic is, but we know that only a tiny fraction is actual curl downloads. A huge portion of this traffic is clearly not human-driven. ## GitHub activity More than two hundred pull requests were opened each month in curl’s GitHub repository. For a brief moment during the fall we reached _zero_ open issues. We have over 220 separate CI jobs that in the end of the year spend more than 25 CPU days per day verifying our ongoing changes. ## Dashboard The curl dashboard expanded a lot. I removed a few graphs that were not accurate anymore, but the net total change is still that we went up from 82 graphs in December 2024 to 92 separate illustrations in December 2025. Now with a total of 259 individual plots (+25). ## Dropped support We removed old/legacy things from the project this year, in an effort to remove laggards, to keep focus on what’s important and to make sure all of curl is secure. * Support for Visual Studio 2005 and older (removed in 8.13.0) * Secure Transport (removed in 8.15.0) * BearSSL (removed in 8.15.0) * msh3 (removed in 8.16.0) * winbuild build system (removed in 8.17.0) ## Awards It was a crazy year in this aspect (as well) and I was honored with: * European Open Source Achievement Award 2025 * Developer of the year 2025 * Swedish IVA Gold Medal 2025 I also dropped out of the Microsoft MVP program during the year, to which I was accepted into in October 2024. ## Conferences / Talks I attended these eight conferences and talked – in five countries. My talks are always related to curl in one way or another. * FOSDEM * foss-north * curl up * Open Infra Forum * Joy of Coding * FrOSCon * Open Source Summit Europe * EuroBSDCon ## Podcasts I participated on these podcasts during the year. Always related to curl. * Security Weekly * Open Source Security * Day Two DevOps * Netstack.FM * Software Engineering Radio * OsProgrammadores

daniel.haxx.se