I released a security fix for OCaml’scohttp 6.3.0today, fixing apath 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 thePR to fix the issue.
What’s worse, I found I could use my own agents to find the exploitjust by knowing roughly what it was aboutand so could have been exploiting it well before the public patch was available!
Given that just therumourof 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.
This particular report arrived privately on a Slack channel via Jane Street last week, and was itself found via Claude Fable. That compresses all timelines considerably…
Before examining the patch in detail, I pointed my own Claude at the affected code to see what else was lurking (asking it to investigate path normalisation issues). Fable frustratingly refused outright due to its security block since Idon’t have access to Glasswing, butDeepSeek V4 Proobliged me and independently turned up several related issues. My agent also trivially created an exploit to probe a local live server in under a minute.
After some back and forth with the bug reporter about possible fixes, I quietly openedcohttp#1145publicly toget more eyeson it. This normally takes a few days and a release within a week or two is reasonable. Within about ten minutes (!) this website was fielding probes for percent-encoded traversal sequences, indicating that automated watchers are keeping an eye on public repositories.
If it took me just a minute to create my own exploit locally, thenten minutes actually seems quite longfor an automated attack window to start! A determined attacker who is monitoring package repositories could easily be exploiting them within seconds.
Conventional security process involvesembargoingthe 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 agentexploited 87%of a 15-vulnerability benchmark, and without the description, just 7%.
Two years on, themean time to exploitis -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’sCVE-2026-39987went from advisory to first exploitation attempt in 9 hours, even with no public proof-of-concept in existence. Langflow’sCVE-2026-33017took 20 hours. We seem to have crossed the rubicon for automated exploit generation…
It looks to me like our security processes need to invert somewhat, since just one
person searching for the issue class (this could be a mailing list question, an odd
commit in an orphan branch, or a context leak) is sufficient to alert someone
else’s agent and let them get exploit code. This is wild.
A May 2026 paper coined the term “bugonomics”
and argues that the bottleneck has moved to “defender remediation throughput”. LLMs are merrily
generating exploits, but our ability to defend against them isn’t necessarily
improving as maintainer validation, triage and release rates stay flat. This unfortunately
matches the view from my OSS maintainer’s chair:
And why are maintainer capabilities staying flat? Well, not having access
to frontier agents like Mythos is an obvious one, but also that the engineering of a
security patch that doesn’t cause any regressions is just fundamentally more work.
We clearly need to adapt fairly quickly. I don’t think the current manual
triage process should disappear, but I have seen an unsustainable surge of activity since Fable
came out. We are only just beginning to get a handle on how much of the
incoming firehose is machine-generated, but it’s obviously a lot.