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

In the curl 8.23.0 release we shipped a fix for one of the worst vulnerabilities in curl in a long time. We grade it severity HIGH. It is known as CVE-2026-92392 with the title _HTTP/2 upload Use-After-Free_. This post explains the bug, what the problem can lead to, and something about why it happened and what we have done to make it harder to introduce a problem like this in curl again in the future. This is a much simplified explanation. Please refer to the original report for all the details and the full reproducible Docker image for all the low-level fun and education you could possibly want. I highly recommend doing that; the report and the reproducible are awesome. ## Use-After-Free It is a use-after-free, which is a classic problem in memory-unsafe programming languages, like C, where we erroneously have a lingering pointer left, pointing to memory that is already freed, and yet we use that pointer and the memory it points to. This family of errors is especially bad when a malicious actor can affect the content that gets stored into that memory area that is still used even though it was freed. Tricking the program to do something unintended. ## HTTP/2 is multiplexed This problem involves HTTP/2. HTTP/2 is a multiplexed protocol, meaning that it handles multiple logic transfers over the same physical connection. curl needs to keep track of a number of transfers at the same time, and when data arrives or is to be sent off, it needs to keep things apart appropriately. ## Handles For every transfer done using libcurl, the application creates and sets up a dedicated _handle_. We call it an _easy handle_. This handle is kept around for as long as the transfer is in progress, and the application can close and free it once the operation is completed. When doing multiple transfers, multiple handles are used. libcurl also has _multi handles_ , which is a super handle type that holds any amount of _easy handles_. This handle, and the corresponding multi interface, makes it possible to drive any amount of concurrent transfers. A transfer done with libcurl always has at least one multi handle and one easy handle. (Sometimes the multi handle is hiddenly used under the hood.) ## The setup In order to trigger this problem, we need an application (such as the curl command line tool) to do an upload over HTTP/2 to a server. By default, libcurl negotiates HTTP/2 when a HTTPS:// URLs is used and the server agrees. When the upload has started, the server pauses the send by zeroing the HTTP/2 window size, returns a piece of the response and then it resets the stream, which shuts down the transfer – but not the connection. curl then correctly pulls down the entire transfer, but it accidentally leaves a lingering pointer to the involved _easy handle_. When the application finds out that the transfer completed (with an error), it subsequently frees the easy handle and then, and here comes the problematic part: cleans up the multi handle. ## The mistake At this point, the _easy handle_ was just freed but there is still a reference to that handle. When libcurl shuts down the multi handle, it misunderstands the situation, allocates memory to download data into, finds the still dangling pointer and manages to _download data_ from the server that ends up in the very same memory previously used for the easy handle. In this process, it sends off a request that leaks internal client details, which includes information about local addresses, which is crucial. Modern operating systems use Address Space Layout Randomization (ASLR), so a server needs this clue in order to generate a good attack payload. Subsequently, when libcurl deals with this received data (using the handle the dangling pointer points to) in the download buffer, it uses a function pointer that now has been modified by data just downloaded from the server, and then _it runs remote code_. ## An illustration Here’s a simplified 6-step illustration. ## Conditions to trigger In order to actually successfully execute remote code, lots of several specific conditions need to be met and we deem it extremely difficult to meet these requirements in the wild, which is why we decided this is “only” severity HIGH and not CRITICAL. 1. The victim needs to actually attempt to upload data to a malicious server, meaning that the server certificate must remain valid. 2. The size of the upload needs to be roughly the right size (~135KB) 3. The attacker needs to know curl’s architecture to _generate_ and deliver the right code 4. The attack requires a specific sequence of allocations and allocation sizes so that the data from the server ends up in the right place (from the attacker’s view). This pattern differs between Linux distros, libc versions/flavors, TLS certificate bundles, libcurl using applications and more. 5. nghttp2 and OpenSSL/TLS 1.3 behavior, including allocation effects around session tickets 6. The payload storage area is small (around 23 bytes) The most likely outcome of an attempted attack is rather just a crash. We estimate that the chance for a successful attack is slim. ## How was this found? This problem was found and reported by Luna Tong at Anthropic using their new OSS Scanner. Presumably this involves their AI models. ## How do we fix this? In general we have over the last few years been working on reducing the amount of internal pointers to handles that needs to be correct, and instead we store transfer identifiers that we look-up on demand. While this is a tiny bit slower, it is more foolproof when there are logical mistakes like the one mentioned here. We also of course continue to add more tests and we verify the code with more tools and analyzers in order to find additional similar mistakes. Multiplexed protocols like HTTP/2 have this challenge that there are many concurrent transfers going and they all have different life-times and with memory-unsafe languages, dangling pointer mistakes can indeed be fatal. This is of course no guarantee that we do not have or will not introduce another use-after-free in the code now or later. ## Again on the language libcurl is written in C – a memory unsafe language. With a _memory-safe_ language, this mistake could probably have been avoided. We have worked on curl for almost thirty years, and have over this time manage to make a rather polished transfer engine. For the longest time there really was no memory-safe alternative that also allowed libcurl to be a low-level library available on hundreds of operating systems and several dozen CPU architectures. It even barely exist alternatives now. We do not rewrite curl. Not into another language but also not in C. We are set to iterate, polish, improve, refactor over and over until the end of time. Porting curl to another language (like rust) would be a monstrous undertaking that would be slow and introduce lots of new short to medium term problems. Not to mention that the existing curl team is not rust experts and that libcurl is currently portable to many more platforms and environments than rust itself is. ## Release schedule When this vulnerability was confirmed by the curl security team just hours after it was submitted to us on September 15. We immediately realized the significance and decided to rush the pending next release. However, we still wanted to be careful, follow the procedures and not create any further problems or mistakes by stressing it too much. That’s how we ended up just shortening the release cycle with two weeks. Down from eight to six weeks from the previous release. This allowed us to also merge and fix many more vulnerabilities and general bugs in the same release. ## CVSS We never provide CVSS for our published vulnerabilities as we don’t think we can do a job there. Others will provide them even for our flaws.

PowerShell is a spiced up command line shell made by Microsoft. According to some people, it is a really useful and good shell alternative. Already a long time ago, we got bug reports from confused users who couldn’t use curl from their PowerShell prompts and it didn’t take long until we figured out that Microsoft had added aliases for both curl and wget. The alias had the shell instead invoke its own command called “Invoke-WebRequest” whenever curl or wget was entered. Invoke-WebRequest being PowerShell’s own version of a command line tool for fiddling with URLs. Invoke-WebRequest is of course not anywhere near similar to neither curl nor wget and it doesn’t support any of the command line options or anything. The aliases really don’t help users. No user who would want the actual curl or wget is helped by these aliases, and users who don’t know about the real curl and wget won’t use the aliases. **They were and remain pointless.** But they’ve remained a thorn in my side ever since. Me knowing that they are there and confusing users every now and then – not me personally, since I’m not really a Windows guy. Fast forward to modern days: Microsoft released PowerShell as open source on github yesterday. Without much further ado, I filed a Pull-Request, asking the aliases to be removed. It is a minuscule, 4 line patch. It took way longer to git clone the repo than to make the actual patch and submit the pull request! It took 34 minutes for them to close the pull request: > “Those aliases have existed for multiple releases, so removing them would be a breaking change.” To be honest, I didn’t expect them to merge it easily. I figure they added those aliases for a reason back in the day and it seems unlikely that I as an outsider would just make them change that decision just like this out of the blue. But the story didn’t end there. Obviously more Microsoft people gave the PR some attention and more comments were added. Like this: > “You bring up a great point. We added a number of aliases for Unix commands but if someone has installed those commands on WIndows, those aliases screw them up. > > We need to fix this.” So, maybe it will trigger a change anyway? The story is ongoing…

A synthetic library for bigstrings. Contribute to robur-coop/bstr development by creating an account on GitHub.

Over the years, we have received, read and handled way over _one thousand_ vulnerability reports filed against curl. We have seen most kinds. It is time for me to try to help future reporters by providing a short guide on how to submit a truly excellent vulnerability report to an Open Source project. ## **Researchers** We tend to call everyone who reports a security problem a _security researcher_ , because by the act of the submission itself they fulfill the definition. There are however many different kinds of people who submit reports; from the most rookie youngster with limited experience, to the multi-decade experienced senior in the field. Most reports submitted to a project like curl come from reporters who never submitted anything to the project before and are completely previously unknown. Many reporters use hacker handles or pseudonyms, so there is not a lot to learn about the person behind the report either. We don’t know the reporters’ age, experience level, employer, sex or on which continent they live. But also: none of those things matter. When you submit a vulnerability report, consider telling the project how you want to get credited, should they consider your report real. There is a potentially almost unlimited amount of security researchers that can find problems in a project. The project receiving your report only has a limited small number of overloaded maintainers that take care of the reports. Consider this imbalance. Make your report as easy as possible for the team to manage. ## **Finding** To us maintainers who receive a steady stream of vulnerability reports, it rarely matters exactly _how_ the problem was detected. Whether you fell over it by accident, you found it by reading every single line of source code or if an AI pointed it out to you, it has little relevance to the security team. The team primarily cares about if the problem is _real_ and if it is, _how serious the impact is_. ## **Really?** If the problem is documented, then it likely isn’t a vulnerability. This is a common theme in curl: people report that they can find something strange or peculiar to happen when they do something, only to have one of us point out that the action is either documented to have that side-effect, or the action was done in spite of clear warnings in the documentation. To make a good vulnerability report, you should _make sure_ you understand what the software is supposed to do – and what the documentation says its limitations and conditions are. A good Open Source project has those things documented. ## **Where** Figure out where and how to submit your report. If you found several problems, it is considered polite to ask the team how they want to receive the rest. As separate individual submissions or maybe as a curated list. Perhaps paced at a slow rate to avoid overflow. _Never_ circumvent the submission method suggested by the project. That is impolite. Consider the initial submitting of the issue to be the first step in a multi-step communication process with the project that will continue for as long as at least one of your reported issues has not been resolved or dismissed. This can be days, weeks or in some cases even months. Expect responses and follow-up questions. Be prepared to clarify, expand and maybe provide more code and reasoning. Remember that you submit vulnerability reports in order to help and improve the project. ## **Report** These days people like to create enormously long and detailed reports that have all the details, often explained three times and with several embedded lists using bullet points describing impact and providing more or less good analysis attempts. Your first paragraph of the report should be a human-written, brief explainer of what the problem is and what badness it leads to. You should be able to explain that in just a few sentences. It is a reality-check, because if you can’t do this, if you don’t understand the flaw enough yourself to write such a paragraph, then you have homework to do. Figure it out, then come back and write the intro paragraph. Having a quality intro saves a lot of time for the security team receiving your report. Be aware that the Open Source project you contact may be overloaded, on vacation or seeing your report as yet another duplicate they already saw reported seven times. Be helpful and respect that you add a load to a small team that probably consists of volunteers working on this in their spare time. Even if you have used a lot of or just a little AI when finding the issue and writing up the report, you must make sure that you _communicate as a human_. With your human communication skills. ## **Reproducer** Your report should contain a reproducer. Ideally a fully contained and stand-alone script or source code that the security team can build and run to see the vulnerability trigger. A reproducer helps prove to the team that the problem is real or maybe already an accepted risk or behavior. It is also convenient for the developers to first understand and reproduce the issue, and then they can convert the reproducer into a project test case for the pending fix. _Without_ providing a reproducer in your report, you instead push that work to the receiving end. We still need the reproducer. We still need a test case. ## **Patch** Provide a patch for the problem. If you can figure out a way to fix the code to make your finding no longer trigger, that is great information for the security team and such a patch usually helps them understand the issue better and get a speedier result. It reduces the load. Sure, such a patch is often perhaps not perfect and it can usually be improved and expanded as the developers have a different view and a more nuanced understanding of the problem and the software architecture involved. It still helps. Getting 80% towards the target is still valuable. ## **Versions** Usually you should look for vulnerabilities in the latest version of the software, often even using an up-to-date git repository. Whatever version you used to find it, you need to specify that in your report. If the problem turns out to be real, which your report claims and you should never report anything if you don’t think so, it is then also immediately interesting to know _when this problem first appeared_. Which is the earliest version of the software that you can trigger this problem with? The project will want to know this to write up a proper advisory for the issue. You can help figuring this out by bisecting etc. ## **Collaborate** Remain available after your initial submission. In the curl project at least, we want to work with the reporter to make sure we get every angle and detail right. First, when trying to understand and assess the initial report and agreeing on a severity for it. Then, we jointly produce and agree to a remedy (patch) for the problem, which ideally means taking the reporter’s version and massaging it into perfection. If the problem is serious enough, there could be reasons to discuss a rushed patch release at an earlier date than the pending release would otherwise happen on. To reduce the time users in the wild remain vulnerable. Finally, we collaborate on the description and explainer for the problem that goes into the _security advisory_. ## **Advisory** For every CVE that is registered and assigned to a particular vulnerability, there needs to be a detailed security advisory written. It should ideally describe the issue, how it triggers, what it means, the impact, the affected version ranges and more. Everything related to the vulnerability that we can think might help users. Your job as a security researcher is to make sure the description in the advisory matches your finding, your understanding of the problem and that the description is understandable. ## **Learn** For every confirmed security report, the receiving project will try to learn from it and fix code and practices to avoid making the same mistake again. As a reporter, your job is to learn from the submission experience and try to improve your reporting procedure and approach for the next time. _Then submit your next report!_

Coordinated, confidential vulnerability remediation for the open source software critical infrastructure depends on

RFC 10008 is brand new a specification detailing the new HTTP method called QUERY: _This specification defines the QUERY method for HTTP. A QUERY requests that the request target process the enclosed content in a safe and idempotent manner and then respond with the result of that processing. This is similar to POST requests but can be automatically repeated or restarted without concern for partial state changes_ ## A GET with body For all practical purposes you can think of QUERY as a way to send a GET with a body. It looks exactly like POST, but done with another verb. Contrary to POST, QUERY requests are _idempotent_ – they can be retried or repeated when needed, for instance after a connection failure. ## curl it You can use curl to do HTTP requests with QUERY just fine. curl offers the `--request` option (also known as -X in the short form) that you can use like this: curl -d "data to send" -X QUERY https://example.com/ ## But redirects! There is one little caveat to remember with this curl option that changes the method. When _also_ asking curl to follow any possible redirects, it is important that you use a new enough curl version because you want the `--follow` option. **Not** the old `--location/-L` one. Why? Because the old option changes the HTTP method on all subsequent requests independently of what the server responds, which in many cases is not what you want. The newer `--follow` option instead acts according to what the HTTP response code suggests in should do. Stick to the same method again, or maybe switch to GET in the following request. ## Why? Why or when would you use this? First of course you only want to use this if the server supports it, but the spec offers some reasons why this might be a good choice: * avoid or circumvent URL size limits. Somewhere around 8000 bytes they start to no longer work reliably because servers and intermediaries set limits. * expressing certain kinds of data in the URL is inefficient because encoding overhead * URLs are more likely to be logged than request content

**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

A sandboxed execution environment for unikernels. Contribute to Solo5/solo5 development by creating an account on GitHub.

Here is an initial attempt to optimise our unikernels with regard to hvt. To fully understand the original problem: every time we want to write an Ethernet frame, our execution path is as follows: ...

This PR upstreams Merlin's typing recovery to the OCaml Typechecker. This new mechanism can be enabled with the -typing-recovery cli flag. When running in that mode, the typer won't stop at...

On cognitive DDoS and AI screen time for code, a proposal for voluntary disclosure in OCaml, iOS misery, releasing GeoTessera 0.8 and spatial indexing and the FP Launchpad launch at IIT Madras.

Proposing a voluntary, machine-readable AI content disclosure scheme for OCaml spanning opam packages, dune, and per-module attributes, aligned with the W3C AI Content Disclosure vocabulary.

Publishing the OxCaml Labs year-one review, POSSE and AI content disclosure for the web, adopting the geo-embeddings Zarr convention for TESSERA, action PROPL at PLDI, the death of the grant application, and NASA's new swathe lidar mission.