From the article:

I released a security fix for OCaml's cohttp 6.3.0 today, fixing a path traversal issue. The patch itself was straightforward and in normal times, the security procedure would have been to fix it privately, inform affected users, and then issue a public advisory. This time around though, I noticed probes in my live webserver logs with the exact bug pattern just minutes after opening the PR to fix the issue.

What's worse, I found I could use my own agents to find the exploit just by knowing roughly what it was about and so could have been exploiting it well before the public patch was available! Given that just the rumour of a security issue seems enough to give attackers enough info to find new exploits, we're going to need to change the way we deal with security responses in open source.

[...]

Conventional security process involves embargoing the bug, and assumes that secrecy of the details protects users. However, all an agent needs today is a broad direction to search in, and it can do its own research. Fang et al. found that when given a CVE description, their GPT-4 agent exploited 87% of a 15-vulnerability benchmark, and without the description, just 7%.

Two years on, the mean time to exploit is -7 days. In other words, exploitation now precedes the patch! That same metric looks to be around 63 days in 2018-19, and crossed zero in 2024. A quick search finds lots of other similar cases these days... marimo's CVE-2026-39987 went from advisory to first exploitation attempt in 9 hours, even with no public proof-of-concept in existence. Langflow's CVE-2026-33017 took 20 hours. We seem to have crossed the rubicon for automated exploit generation...

[...]

The big engineering shops (like Google) have been building microupdates directly into their software to ensure that fixes directly reach users as a priority over (e.g.) being fixed in the Chrome code repository. We don't really have that kind of luxury in Docker or OCaml, as we don't control the endpoints our software is used in. Aside from Docker Desktop⁠3, downstream distributions quite rightly repackage OSS on their own timescales and terms.

[...]

Another thing we could do is to rapidly fix issues in public, ship continuously, and improve the release path via better automation.

[...]

However, software packaging is our primary obstacle. Chrome has a relatively easy job of shipping one binary artefact, but OSS is often a bunch of libraries that are then embedded⁠5 in a variety of downstream products. So to do this, we'll need:

• much better cross-ecosystem package management⁠6 to discover where disparate libraries are eventually embedded. Ryan Gibb⁠7 will talk about this at ICFP next week!

• better scanning tools to help with triage; Andrew Nesbitt has been doing just this with Scrutineer over the past few months. Thomas Gazagnaire⁠8 and I have been discussing trying this out for our OCaml code, subject to getting access to a reasonable frontier model without security blocks.

• more robust quality control infra without any false positives that works across the spectrum of supported platforms. While it's relatively easy to run CI on Linux, it's a different story on OpenBSD, FreeBSD, macOS, and some architectures like RISC-V