daniel:// stenberg://

daniel:// stenberg://

@daniel.haxx.se

I write curl. I don't know anything. I am @bagder@mastodon.social My mastodon posts are mirrored to Blusky here: https://bsky.app/profile/bagder.mastodon.social.ap.brid.gy Weekly email at https://lists.haxx.se/listinfo/daniel

5.3K followers98 following205 posts

daniel:// stenberg:// reposted

daniel:// stenberg://
@bagder.mastodon.social.ap.brid.gy

“ignore the slop” https://daniel.haxx.se/blog/2026/10/22/ignore-the-slop/

daniel.haxx.se“ignore the slop”Lots of people who are against the use of AI for all its ethical and inherent issues tell me this. _Just ignore it_. Don’t let _big AI_ control us. The “slop” they refer to is anything created that involved an AI, and in our case (the curl project) it is in particular vulnerability reports. “Ignoring the slop” _cannot be done_ and it doesn’t help. Vulnerability reports created with the help of AIs point out actual problems, and sometimes vulnerabilities. Ignoring real vulnerabilities because they were found by AI does not make users safe and secure. It makes them vulnerable. _We don’t want that_. I personally don’t refer to this as _AI slop_ because the reports are typically accurate and correct, even if much too wordy. I think “slop” implies that it is wrong, misleading or otherwise bad content. One can certainly object to the use of AI, but when we get real vulnerabilities reported and proven, we cannot in good faith pretend they don’t exist just because we think the tech involved in digging them up is questionable. That would be a disservice to, or even betrayal of, our users. We make curl secure for our users. ## Obligations An Open Source project typically gives no guarantees at all, so there are no _legal_ requirements that force us to fix flaws. We are however a project with high goals of quality and stability and we would jeopardize our name and track record if we now would stop delivering on that. Also, a few of us involved in the project also sell curl related support and services, where at least part of that means providing _secure_ curl releases, so we still have this _contractual obligation_ to a set of customers. And they wouldn’t be customers in the fist place if the Open Source project didn’t already have the proven quality track record. So no, we really cannot ignore vulnerability reports. ## The slop is gone A sizeable portion of users seem to still believe we still suffer from a lot of made up and hallucinated reports by these AIs. We really don’t. Almost all the stupidity and lies we saw in the vulnerability reports made by AIs in the past have ceased. Since spring 2026 the slop reports are practically gone. Our current challenge is much harder: high volume, high quality. ## AI talks too much They always use too many words. Every report is now hundreds of lines and the explanations are convoluted and detailed (and often repeat themselves multiple times). In a good report, the human writes a first paragraph explaining the problem _briefly_ and then they submit the full report. It’s annoying when the reporter surrender everything to the AI, including the communication part. The AIs are also still bad at figuring out exactly there the line is between a bug and a vulnerability, and if it is a vulnerability, what severity it is. This is not a surprise though, as this is also the case for human reporters. A good trend is that they often produce good reproducers or proofs of concept helping to trigger and prove the problem/vulnerability. That was a really complicated part of the reporters’ work back in the day, now it’s just a prompt or two. ## Everything is with AI now These days, like within the last few months, we have received hundreds of vulnerability reports submitted to curl and _every single one had AI involved to some extent_. It is generally easy to tell on the language and the length and details of the report.

daniel:// stenberg:// reposted

daniel:// stenberg://
@bagder.mastodon.social.ap.brid.gy

Do minor #curl vulnerabilities in the open (Starting Monday October 26) https://daniel.haxx.se/blog/2026/10/20/do-minor-curl-vulnerabilities-in-the-open/

daniel.haxx.seDo minor curl vulnerabilities in the openThe curl project has decided to alter its vulnerability disclosure program procedure and starting _**October 26 2026**_ , we insist that all vulnerability reports submitted to us that are deemed to be severity LOW or MEDIUM should instead be submitted as issues in our GitHub repository. Only vulnerabilities deemed to be HIGH or CRITICAL will be kept private in the HackerOne tracker. Security researchers in doubt can still submit the issue on HackerOne and we can tell them what severity we deem it to be. Over the last few years, over 90% of all submissions could quickly be assessed to be less than HIGH. Issues submitted to HackerOne we deem are LOW or MEDIUM will be requested to be resubmitted on GitHub and will be closed as informative on HackerOne (and publicly disclosed). ## Avalanche survival tricks This policy change is entirely triggered by the current avalanche of vulnerability reports that keep pouring in. We see no end to them and we do not anticipate this flood to decrease within the next several months. We are struggling as a project as all key maintainers feel strained, overloaded and brought to the brink of what we can muster. We _must_ act to survive. This is our next step in a survival strategy. It might not be our last. We aim to not drown. ## Public vs private By opening up the process we allow the whole world to participate. Both in the assessment and understanding of the report and claimed vulnerability, but also in the creating and writing the advisory and figuring out details of when the issues was introduced etc. Ideally we get better help to make sure the fix is the correct one, that it fixes the problem, and any other related problem that is similar and that it does not miss a related problem sitting next to this. An obvious recent trend is that the moment we announce a new set of CVEs and their associated fixes, there is an army of AI-using researchers who throw all those at their models and harnesses to find similar mistakes or omissions in the fixes. By taking this process to the public all the way, ideally we get more help to do that scrutiny better _before_ we ship releases. We recognize that the amount of work needed per received vulnerability report does not shrink by doing them in public, but we think that we might share the burden among more people easier, and we hope that lessons and documentation brought up in these discussions will be easier to spot and learn from. ## The risks Several people have suggested there is a risk that researchers mistakenly submit severity HIGH issues on GitHub thinking they are LOW or MEDIUM. It is basically unheard of that a researcher would have _understated_ a reported problem so I consider that a low risk scenario. Also: there was already before this a risk that someone would submit a vulnerability report in the public, it is not a new risk. Handling some vulnerabilities in the public of course makes the immediately available for both good and bad people. This policy will give bad people a slightly longer window of opportunity to exploit weaknesses at the expense of existing curl users. That is unfortunate but we see no way of avoiding this. We limit this practice to less than HIGH for this reason: at least these problems are not terrible. ## Severity LOW We have discussed simply dismissing all severity LOW issues, but within the CVE program there is an appeals process and if we don’t hand out a CVE to an actual vulnerability, then someone else will do it. We thus cannot ignore true vulnerabilities, or they will come back to bite us nonetheless. We _can_ however resist and refuse silliness and I personally aim to deny and decline more vulnerabilities harder on the basis that they do not actually hurt any users or existing applications. ## Crazy combos A clear trend these days is that many newly reported vulnerabilities are figured out by AI models that create crazy sequences or option combinations that do something unexpected, but the sequence is something that aren’t likely to ever be used in the real world, or the unexpected that happens is something that occurs _every time_ so applications doing this would spot the problem immediately. I.e problems that have almost no risk to actually trigger in the real world. We save no users by insisting on doing the CVE dance for those issues. We only get work for ourselves and a whole world that has to act on them. ## Flow control it There is an almost infinite number of combinations you can use libcurl’s many options, protocol mixes and flexible API to do things that might not be clearly documented and the AIs will continue to try them all and together with the humans driving these checks they are super eager to treat every minor discrepancy as a vulnerability. We can’t continue down this spiraling path with our sanity intact. We don’t have the bandwidth, manpower or even will to handle a never-ending vulnerability reporting stream at this pace. I believe few software projects can stand this kind of prolonged high volume deluge for extended periods. Something needs to give way. ## How to assign severity We only use these for levels in the curl project: LOW, MEDIUM, HIGH and CRITICAL. Often we refer back to recently managed vulnerabilities to see how we judged them, but we also provide a set of basic guidelines. I’m sure we can also make them better and clearer.

daniel:// stenberg:// reposted

daniel:// stenberg://
@bagder.mastodon.social.ap.brid.gy

Twenty-two pending #curl vulnerabilities https://daniel.haxx.se/blog/2026/10/07/twenty-two-pending-curl-vulnerabilities/

daniel.haxx.seTwenty-two pending curl vulnerabilitiesOn October 14 2026 we will ship curl 8.23.0. The next iteration in the never-ending series of version bumps from the curl project. We always think of the next release as the best version we ever did – and this time is no exception. Decades of collected experiences and meticulous polishing has lead us to this. ## Earlier than planned We decided to shorten the release cycle this time, so that we can release 8.23.0 a few weeks earlier than what we originally planned. We took this decision after we received one particular vulnerability report that highlighted a rather significant flaw. We will ship a new version with this problem removed, together with twenty-one other albeit less serious security vulnerabilities addressed. ## Severity HIGH In the curl project we only assign one of the four different severity levels on all CVEs we report (LOW, MEDIUM, HIGH or CRITICAL), as we basically don’t believe in CVSS scoring. We have only published two CVEs with severity HIGH since 2021, the most recent one being CVE-2023-38545; that could lead to a heap buffer overflow. Now we are about to release another one: CVE-2026-92392. ## All info will be revealed next week All details about CVE-2026-92392 will become public in the European morning of October 14, 2026 in synchronization of the release of curl 8.23.0 which of course will have this problem fixed. We will ship updated Rock-solid curl versions in sync with this. For the safety and security of curl users everywhere (and frankly, all the infrastructure that uses curl), no details of this flaw will be made public before this date. We will alert the distros@openwall mailing list and paying curl support customers about this problem (and the associated fix) ahead of time. I will follow-up with a separate blog post after October 14 to describe this flaw in detail. How it can be triggered, why it isn’t quite the end of the world and what we do in curl to fix this and similar classes of problems.

daniel:// stenberg:// reposted

daniel:// stenberg://
@bagder.mastodon.social.ap.brid.gy

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

daniel.haxx.seHTTP Message Signatures with curlThe 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:// stenberg:// reposted

daniel:// stenberg://
@bagder.mastodon.social.ap.brid.gy

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

daniel.haxx.seWorkshop Basel day oneOn 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:// stenberg:// reposted

daniel:// stenberg://
@bagder.mastodon.social.ap.brid.gy

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

daniel.haxx.securl 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:// stenberg:// reposted

daniel:// stenberg://
@bagder.mastodon.social.ap.brid.gy

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/

daniel.haxx.securl 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:// stenberg:// reposted

daniel:// stenberg://
@bagder.mastodon.social.ap.brid.gy

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

daniel.haxx.seA human in controlThere 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:// stenberg:// reposted

daniel:// stenberg://
@bagder.mastodon.social.ap.brid.gy

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

daniel.haxx.seMythos finds a curl vulnerabilityyes, 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:// stenberg:// reposted

daniel:// stenberg://
@bagder.mastodon.social.ap.brid.gy

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

daniel.haxx.securl 8.20.0You 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:// stenberg:// reposted

daniel:// stenberg://
@bagder.mastodon.social.ap.brid.gy

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/

daniel.haxx.seHigh-Quality ChaosAs 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:// stenberg:// reposted

daniel:// stenberg://
@bagder.mastodon.social.ap.brid.gy

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

daniel.haxx.sechicken nugetBackground: 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:// stenberg:// reposted

daniel:// stenberg://
@bagder.mastodon.social.ap.brid.gy

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.

daniel:// stenberg:// reposted

daniel:// stenberg://
@bagder.mastodon.social.ap.brid.gy

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

daniel.haxx.seThe end of the curl bug-bountytldr: 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:// stenberg:// reposted

Olle E. Johansson
@oej.edvina.net

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!

daniel:// stenberg:// reposted

daniel:// stenberg://
@bagder.mastodon.social.ap.brid.gy

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

daniel.haxx.securl 8.18.0Download 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:// stenberg:// reposted

daniel:// stenberg://
@bagder.mastodon.social.ap.brid.gy

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

daniel.haxx.seA curl 2025 reviewLet’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:// stenberg:// reposted

daniel:// stenberg://
@bagder.mastodon.social.ap.brid.gy

#curl 8.17.0 is here. Enjoy! https://daniel.haxx.se/blog/2025/11/05/curl-8-17-0/

daniel.haxx.securl 8.17.0Download curl from curl.se. ## Release presentation As per tradition, there will be a live-streamed release presentation on twitch at 09:00 UTC (10:00 CET) on the release day. Available on YouTube after the fact. ## Numbers the 271st release 11 changes 56 days (total: 10,092) 448 bugfixes (total: 12,537) 699 commits (total: 36,725) 2 new public libcurl function (total: 100) 0 new curl_easy_setopt() option (total: 308) 1 new curl command line option (total: 273) 69 contributors, 35 new (total: 3,534) 22 authors, 5 new (total: 1,415) 1 security fixes (total: 170) ## Security CVE-2025-10966: missing SFTP host verification with wolfSSH. curl’s code for managing SSH connections when SFTP was done using the wolfSSH powered backend was flawed and missed host verification mechanisms. ## Changes We drop support for several things this time around: * drop Heimdal support * drop the winbuild build system * drop support for Kerberos FTP * drop support for wolfSSH And then we did some other smaller changes: * up the minimum libssh2 requirement to 1.9.0 * add a notifications API to the multi interface * expand to use 6 characters per size in the progress meter * support Apple SecTrust – use the native CA store * add `--knownhosts` to the command line tool * wcurl: import v2025.11.04 * write-out: make `%header{}` able to output _all_ occurrences of a header ## Bugfixes We set a new project record this time with no less than 448 documented bugfixes since the previous release. The release presentation mentioned above discusses some of the perhaps most significant ones. ## Coming next There a small set of pull-requests waiting to get merged, but other than that our future is not set and we greatly appreciate your feedback, submitted issues and provided pull-requests to guide us. If this release happens to include an annoying regression, there might be a patch release already next week. If we are lucky and it doesn’t, then we aim for a 8.18.0 release in the early January 2026.

daniel:// stenberg:// reposted

daniel:// stenberg://
@bagder.mastodon.social.ap.brid.gy

A gold ceremony to remember https://daniel.haxx.se/blog/2025/10/25/a-gold-ceremony-to-remember/

daniel.haxx.seA gold ceremony to rememberThere are those moments in life you know already from the start are going to be the rare once in a lifetime events. This evening was one of those times. On a dark and wet autumn Friday afternoon my entire family and me dressed up to the most fancy level you can expect and took at taxi to the Stockholm City Hall. Anja my wife and my kids Agnes and Rex. Rex, Agnes, Daniel, Anja. The Stenberg family. This was the Swedish Royal Academy of Engineering Science’s (IVA) 106th _Högtidssammankomst_ (“festive gathering”) since its founding in 1919. Being one the four gold medal recipients of the night our family got a special dedicated person assigned to us who would help us “maneuver” the venue and agenda. Thanks Linus! In the _golden hall_ me and Anja took a seat in our reserved seats in the front row as the almost 700 other guests slowly entered and filled up every last available chair. The other guests were members of the Academy or special invitees, ministers, the speaker of the parliament etc. All in tail coats, evening dresses and the likes to conform with the dress code of the night. The Golden Hall before people arrived The golden hall is named after its golden colored walls, all filled up with paintings of Swedish historic figures contributing to a pompous and important atmosphere and spirit. _This is the kind of room you want to get awards in._ Part of the program in this golden hall was the gold medal awards ceremony. After having showed short two-minute videos of each of the awardees and our respective deeds and accomplishments on the giant screen in the front of the room, us awardees were called to the stage. The video shown about me and curl. Swedish with subtitles Three gold medals and one large gold medal were handed out to my fellow awardees and myself this year. Carl-Henric Svanberg received the _large_ gold medal. Mats Danielsson and Helena Hedblom were awarded the gold medal. The same as I. The medals were handed to us one by one by Marcus Wallenberg. Photographer: Erik Cronberg. Marcus and me shaking hands. with Helena Hedblom on the right. Photographer: Erik Cronberg. Marcus on the left, me in the middle and Mats Danielsson behind me. In one of the agenda items in the golden hall,IVA’s CEO _Sylvia Schwaag Serger_ did a much inspiring talk about Swedish Engineering and mentioned an amazing list of feats and accomplishments done over the last year and with hope and anticipation for the future. I and curl were also mentioned in her speech. Even more humbled. The audience here were some of the top minds and Engineering brains in Sweden. Achievers and great minds. The kind of people you want appreciation from because they know a thing or two. ## Intermission A small break followed. We strolled down to the giant main hall for some drinks. The blue hall, which is somewhat famous to anyone who ever watched the Nobel Prize banquets. Several people told me the story that the original intent was for the walls to be blue, but… The blue hall that isn’t very blue Projecting patterns on the walls ## Banquet At about 19:00, me and Anja had to sneak up a floor again together with crowd of others who were seated on that main long table you can see on the photo above. Table 1. On the balcony someone mentioned I should wear the prize. So with some help I managed to get it around my neck. It’s not a bad feeling I can tell you. Daniel, wearing the IVA gold medal. As everyone else in the hall had found their ways to their seats, we got to do a slow procession walking down the big wide stairs down into the main hall and find our ways to our seats. Then followed a most wonderful three-course meal. I had excellent table neighbor company and we had a lively and interesting conversation all through the dinner. There were a few welcome short interruptions in the form of speeches and music performances. A most delightful dinner. After the final apple tart was finished, there was coffee and more drinks served upstairs again, as the golden hall had apparently managed to transition while we ate downstairs. Disco(?) in the golden hall When the clock eventually approached midnight the entire Stenberg family walked off into the night and went home. A completely magical night was over but it will live on in my mind and head for a long time. Thank you to every single one involved. ## The medal The medal has an image of Prometus on the front side, and _Daniel Stenberg 2025_ engraved on the back side. On the back it also says the name of the Academy and _för framstående gärning_ , for outstanding achievement. A medal to be proud of. In the box Front side Back side Of course I figured this moment in time also called for a graph. Gold medals for curl over time

daniel:// stenberg:// reposted

daniel:// stenberg://
@bagder.mastodon.social.ap.brid.gy

A new breed of analyzers. And they use AI. https://daniel.haxx.se/blog/2025/10/10/a-new-breed-of-analyzers/

daniel.haxx.seA new breed of analyzers(See how I cleverly did not mention AI in the title!) You know we have seen more than our fair share of slop reports sent to the curl project so it seems only fair that I also write something about the state of AI when we get to enjoy some positive aspects of this technology. Let’s try doing this in a chronological order. ## The magnitude of things curl is almost 180,000 lines of C89 code, excluding blank lines. About 637,000 words in C and H files. To compare, the original novel War and Peace (a _thick_ book) consisted of 587,000 words. The first ideas and traces for curl originated in the httpget project, started in late 1996. Meaning that there is a lot of history and legacy here. curl does network transfers for 28 URL schemes, it has run on over 100 operating systems and on almost 30 CPU architectures. It builds with a wide selection of optional third party libraries. We have shipped over 270 curl releases for which we have documented a total of over 12,500 bugfixes. More than 1,400 humans have contributed with commits merged into the repository, over 3,500 humans are thanked for having helped out. It is a very actively developed project. ## It started with sleep On August 11, 2025 there was a curl vulnerability reported against curl that would turn out legitimate and it would later be published as CVE-2025-9086. The reporter of this was the Google Big Sleep team. A team that claims they use “an AI agent developed by Google DeepMind and Google Project Zero, that actively searches and finds unknown security vulnerabilities in software”. This was the first ever report we have received that seems to have used AI to accurately spot and report a security problem in curl. Of course, we don’t know how much AI and how much human that were involved in the research and the report. The entire reporting process felt very human. ## krb5-ftp In mid September 2025 we got new a security vulnerability reported against curl from a security researcher we had not been in contact with before. The report which accurately identified a problem, was not turned into a CVE only because of sheer luck: the code didn’t work for other reasons so the vulnerability couldn’t actually be reached. As a direct result of this lesson, we ripped out support for krb5-ftp. ## ZeroPath The reporter of the krb5-ftp problem is called Joshua Rogers. He contacted us and graciously forwarded us a huge list of more potential issues that he had extracted. As I understand it, mostly done with the help of ZeroPath. A code analyzer with AI powers. In the curl project we continuously run compilers with maximum pickiness enabled and we though scan-build, clang-tidy, CodeSonar, Coverity, CodeQL and OSS-Fuzz at it and we always address and fix every warning and complaint they report so it was a little surprising that this tool now suddenly could produce over _two hundred_ new potential problems. But it sure did. And it was only the beginning. ## At three there is a pattern As we started to plow through the huge list of issues from Joshua, we received yet another security report against curl. This time by Stanislav Fort from Aisle (using their own AI powered tooling and pipeline for code analysis). Getting security reports is not uncommon for us, we tend to get 2 -3 every week, but on September 23 we got another one we could confirm was a real vulnerability. Again, an AI powered analysis tool had been used. (At the time I write this blog entry, this particular issue has not been disclosed yet so I can’t link it.) ## A shift in the wind As I was amazed by the quality and insights in some of the issues in Joshua’s initial list he sent over I tooted about it on Mastodon, which later was picked up by Hacker news, The Register, Elektroniktidningen and more. These new reported issues feel quite similar in nature to defects reported by code analyzers typically do: small mistakes, omissions, flaws, bugs. Most of them are just plain variable mixups, return code confusions, small memory leaks in weird situations, state transition mistakes and variable type conversions possibly leading to problems etc. Remarkably few of them complete false positives. The quality of the reports make it feel like a new generation of issue identification. Like in this ladder of tool evolution from the old days. Each new step has taken the notch up a level: 1. At some point I think starting in the early 2000s, the C compilers got better at actually warning and detecting many mistakes they just silently allowed back in the dark ages 2. Then the code analyzers took us from there to the next level and found more mistakes in the code. 3. We added fuzzing to the mix in the mid 2010s and found a whole slew of problems we never realized before we had. 4. Now this new breed, almost like a new category, of analyzers that seem to connect the dots better and see patterns previous tools and analyzers have not been able to. And tell us about the discrepancies. ## 25% something Out of that initial list, we merged about 50 separately identifiable bugfixes. The rest were some false positives but also lots of minor issues that we just didn’t think were worth poking at or we didn’t quite agree with. ## A minor tsunami We (primarily Stefan Eissing and myself) worked hard to get through that initial list from Joshua within only a couple of days. A list we mistakenly thought was “it”. Joshua then spiced things up for us by immediately delivering a _second_ list with 47 additional issues. Follow by a third list with yet another 158 additional potential problems. At the same time Stanislav did the similar thing and delivered to us two lists with a total of around twenty possible issues. Don’t take me wrong. This is good. The issues are of high quality and even the ones we dismiss often have some insights and the rate of obvious false positive has remained low and quite manageable. Every bug we find and fix makes curl better. Every fix improves a software that impacts and empowers a huge portion of the world. The total amount of suspected issues submitted by these two gentlemen are now at over _four hundred_. A fair pile of work for us curl maintainers! Because how these reported issues _might_ include security sensitive problems, we have decided to not publish them but limit access to the reporters and the curl security team. As I write this, we are still working our way through these reports but it feels reasonable to assume that we will get even more soon… ## All code An obvious and powerful benefit this tool seems to have compared to others is that it scans _all_ source code without having a build. That means it can detect problems in all backends used in all build combinations. _Old style_ code analyzers require a proper build to analyze and since you can build curl in countless combinations with a myriad of backend setups (where several are architecture or OS specific), it is literally impossible to have all code analyzed with such tools. Also, these tools can inject (parts of) third party libraries as well and find issues in the borderland between curl and its dependencies. I think this is one primary reason it found so many issues: it checked lots of code barely any other analyzers have investigated. ## A few examples To illustrate the level of “smartness” in this tool, allow me to show a few examples that I think shows it off. These are issues reported against curl in the last few weeks and they have all been fixed. Beware that you might have to understand a thing or two about what curl does to properly follow here. ### A function header comment was wrong It correctly spotted that the documentation in the function header incorrectly said an argument is optional when in reality it isn’t. The fix was to correct the comment. # `Curl_resolv`: NULL out-parameter dereference of `*entry` * **Evidence:** `lib/hostip.c`. API promise: "returns a pointer to the entry in the `entry` argument (**if one is provided**)." However, code contains unconditional writes: `*entry = dns;` or `*entry = NULL;`. * **Rationale:** The API allows `entry == NULL`, but the implementation dereferences it on every exit path, causing an immediate crash if a caller passes `NULL`. I could add that the fact that it takes comments so seriously can also trick it to report wrong things when the comments are outdated and state bad “facts”. Which of course shouldn’t happen because comments should not lie! ### code breaks the telnet protocol It figured out that a piece of telnet code actually wouldn’t comply with the telnet protocol and pointed it out. Quite impressively I might add. **Telnet subnegotiation writes unescaped user-controlled values (tn->subopt_ttype, tn->subopt_xdisploc, tn->telnet_vars) into temp (lines 948–989) without escaping IAC (0xFF)** In lib/telnet.c (lines 948–989) the code formats Telnet subnegotiation payloads into temp using msnprintf and inserts the user-controllable values tn->subopt_ttype (lines 948–951), tn->subopt_xdisploc (lines 960–963), and v->data from tn->telnet_vars (lines 976–989) directly into the suboption data. The buffer temp is then written to the socket with swrite (lines 951, 963, 995) without duplicating CURL_IAC (0xFF) bytes. Telnet requires any IAC byte inside subnegotiation data to be escaped by doubling; because these values are not escaped, an 0xFF byte in any of them will be interpreted as an IAC command and can break the subnegotiation stream and cause protocol errors or malfunction. ### no TFTP address pinning Another case where it seems to know the best-practice for a TFTP implementation (pinning the used IP address for the duration of the transfer) and it detected that curl didn’t apply this best-practice in code so it correctly complained: No TFTP peer/TID validation The TFTP receive handler updates state->remote_addr from recvfrom() on every datagram and does not validate that incoming packets come from the previously established server address/port (transfer ID). As a result, any host able to send UDP packets to the client (e.g., on-path attacker or local network adversary) can inject a DATA/OACK/ERROR packet with the expected next block number. The client will accept the payload (Curl_client_write), ACK it, and switch subsequent communication to the attacker’s address, allowing content injection or session hijack. Correct TFTP behavior is to bind to the first server TID and ignore, or error out on, packets from other TIDs. ### memory leaks no one else reported Most memory leaks are reported when someone runs code and notices that not everything is freed in some specific circumstance. We of course test for leaks all the time in tests, but in order to see them in a test we need to run that exact case and there are many code paths that are hard to travel in tests. Apart from doing tests you can of course find leaks by manually reviewing code, but history and experience tell us that is an error-prone method. # GSSAPI security message: leaked `output_token` on invalid token length * **Evidence:** `lib/vauth/krb5_gssapi.c:205--207`. Short quote: ```c if(output_token.length != 4) { ... return CURLE_BAD_CONTENT_ENCODING; } ``` The `gss_release_buffer(&unused_status, &output_token);` call occurs later at line 215, so this early return leaks the buffer from `gss_unwrap`. * **Rationale:** Reachable with a malicious peer sending a not-4-byte security message; repeated handshakes can cause unbounded heap growth (DoS). This particular bug looks straight forward and in hindsight easy enough to spot, but it has existed like this in plain sight in code for _over a decade_. ## More evolution than revolution I think I maybe shocked some people when I stated that the AI tooling helped us find 22, 70 and then a 100 bugs etc. I suspect people in general are not aware of and does not think about what kind of bugfix frequency we work on in this project. _Fixing several hundred bugs per release is a normal rate for us._ Sure, this cycle we will probably reach a new record, but I still don’t grasp for breath because of this. I don’t consider this new tooling a _revolution_. It does not massively or drastically change code or how we approach development. It is however an excellent new project assistant. A powerful tool that highlights code areas that need more attention. A much appreciated evolutionary step. I might of course be speaking too early. Perhaps it will develop a lot more and it can then turn into a revolution. ## Ethical and moral decisions The AI engines burn the forests and they are built by ingesting other people’s code and work. Is it morally and ethically right to use AI for improving Open Source in this way? It is a question to wrestle with and I’m sure the discussion will go on. At least this use of AI does not generate duplicates of someone else’s code for us to use, but it certainly takes lessons from and find patterns based on others’ code. But so do we all, I hope. ## Starting from a decent state I can imagine that curl is a pretty good source code to use a tool of this caliber on, as curl is old, mature and all the minor nits and defect have been polished away. It is a project where we have a high bar and we want to raise it even higher. We love the opportunity to get additional help and figure out where we might have slipped. Then fix those and try again. Over and over until the end of time. ## AIxCC At the DEF CON 33 conference which took place in August 2025, DARPA ran a competition called the AI Cyber Challenge or AIxCC for short. In this contest, the competing teams used AI tools to find artificially injected vulnerabilities in projects – with zero human intervention. One of the projects used in the finals that the teams looked for problems in, was… curl! I have been promised a report or a list of findings from that exercise, as presumably the teams found something more than just the fake inserted problems. I will report back when that happens. ## Going forward We do not yet have any AI powered code analyzer in our CI setup, but I am looking forward to adding such. Maybe several. We _can_ ask GitHub copilot for pull-request reviews but from the little I’ve tried copilot for reviews it is far from comparable to the reports I have received from Joshua and Stanislav, and quite frankly it has been mostly underwhelming. We do not use it. Of course, that can change and it might turn into a powerful tool one day. We now have an established constructive communication setup with both these reporters, which should enable a solid foundation for us to improve curl even more going forward. I personally still do not use any AI at all during development – apart from occasional small experiments. Partly because they all seem to force me into using VS code and I totally lose all my productivity with that. Partly because I’ve not found it very productive in my experiments. Interestingly, this productive AI development happens pretty much concurrently with the AI slop avalanche we also see, proving that one AI is not necessarily like the other AI.

daniel:// stenberg:// reposted

Help Net Security
@helpnetsecurity.com

Behind the scenes of cURL with its founder: Releases, updates, and security 📖 Read more: www.helpnetsecurity.com/2025/09/18/d... #cybersecurity #cybersecuritynews #vulnerabilitymanagement @daniel.haxx.se

helpnetsecurity.comBehind the scenes of cURL with its founder: Releases, updates, and security - Help Net SecurityExplore how the cURL project keeps billions of devices secure, from vulnerability handling to best practices and updates.
daniel:// stenberg://
@daniel.haxx.se

Awarded!

daniel:// stenberg://@bagder.mastodon.social.ap.brid.gy

I was #awarded Developer of the year yesterday (in Sweden). https://daniel.haxx.se/blog/2025/09/13/developer-of-the-year/

daniel.haxx.seDeveloper of the yearDevelopers Day is a recent annual Swedish gala organized by the Stockholm-based company Developers Bay. This is its third year running. They have an ambition to highlight and celebrate Swedish software _developers_ (or perhaps it is developers based in Sweden?) and hand out a series of awards for that purpose. A jury that consists of six persons receives nominations through-out the year and then they decide which of them who get awards in six different categories. ## Awarded This year, I was graciously nominated as, and subsequently, awarded _Developer of the year_ at the award gala on September 12, 2025. Developer of the Year 2025 “certificate”, in Swedish The motivation, as shown in Swedish in the image above, translates into something like: > This year’s winner is a developer with a lifelong passion for technology and problem solving. His interest was awaken already in the 1980s with a commodore64 and has since grown into a career characterized by curiosity and drive. After starting his professional life at IBM, the developer has contributed to the open source world for a long time – both as a coder and as an ambassador for open collaboration. For this year’s winner, development is also a way to understand people and the most challenging part of technology is the collaboration between them. He created curl, one of the world’s most installed software products, with over 20 billion installations. Getting recognition for my work and many years in software development is truly awesome and heartwarming. It energizes me and motivates me to go further. Clearly I must be doing something right! I aspire to make top quality software entirely free and Open Source. I want to provided stellar tools and means for my fellow developers that make them productive and allow them to build awesome things. I try to explain what I do, how things work and I how I think things should be done, to perhaps in some small ways push things in the world in the appropriate direction. ## The award Yeah, this is probably a little navel-gazing and inside baseball, as this is just a (small) company and its associated network that give out awards within a relatively small Swedish community by jury members who given their public bios do not have a terribly long or extensive experience out in the big wide world. _of the year?_ Yeah a quite legitimate question could be what special action or activity I have done in 2025 to earn the honor this particular time and not last year or next, but I think it simply boils down to the fact that someone nominated me this year. Best developer? Comparing different persons working with completely different things in completely different areas and saying that one of them is “best” is certainly futile and of course not actually possible. We have numerous excellent developers in Sweden. In spite of that, getting recognition in the form of an award is simply wonderful. Thank you!