Advice for FOSDEM attendees. Contribute to bagder/FOSDEM development by creating an account on GitHub.

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

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

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

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

Fix CVE-2025-11563: Don't percent-decode / and \ in output file name to avoid path traversal. Fix typos reported by pyspelling. Multiple improvements to GitHub Actions.

Call for Nominations for European Open Source Awards 2026

There 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

The Royal Swedish Academy of Sciences (IVA, the same org that selects winners for three of the Nobel prize categories) awards me a gold medal 2025 for my work on curl. This academy, established 1919 b...

YouTube video by OsProgramadores

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

Explore how the cURL project keeps billions of devices secure, from vulnerability handling to best practices and updates.

A steadfast pioneer of interoperability, 2025 inductee Patrik Fältström helped connect people across devices and languages.