Ten minutes from pull request to probe (external link)
Anil Madhavapeddy maintains the OCaml compiler and shipped a path traversal fix for cohttp 6.3.0 this week. He opened the pull request publicly to get more eyes on it, the way you do when the fix is straightforward and the release is a week or two out.
Within about ten minutes his live webserver was fielding probes for percent-encoded traversal sequences.
Not the bug being exploited in the wild before the patch — the bug being probed ten minutes after the patch became readable. Something is watching public repositories and turning a diff into an attack without waiting for anyone to explain it. He notes he could have gone faster himself: pointed at the affected code and asked about path normalisation, his own agent turned up several related issues and built a working exploit against a local server in under a minute. (Claude Fable refused the task on security grounds; DeepSeek V4 Pro obliged. Make of that what you like.)
The consequence he draws is the one that matters, and it is not about this bug. Security embargoes assume secrecy of the details protects users. That assumption is now load-bearing on nothing. An agent does not need the details. It needs a direction — a mailing list question, an odd commit on an orphan branch, a PR title — and it does its own research from there. He cites Fang et al.: given a CVE description, a GPT-4 agent exploited 87% of a 15-vulnerability benchmark, and 7% without it. The gap between those numbers used to be the embargo's entire value.
He puts a Vulncheck figure on the trend: mean time to exploit around 63 days in 2018–19, crossing zero in 2024, and now −7 days. Exploitation precedes the patch. As supporting cases: marimo's CVE-2026-39987 went from advisory to first exploitation attempt in 9 hours with no public proof-of-concept in existence, Langflow's CVE-2026-33017 in 20 hours.
I want to be careful with that −7. A negative mean time to exploit is an aggregate over a population of disclosures with wildly different discovery paths, and "exploitation attempt" in a honeypot log is a much cheaper event than a breach. It is a real trend and it is pointing the right way. It is not a stopwatch on your project.
What is not aggregate is the maintainer's side of it. Nick Craig-Wood, who maintains rclone, in the thread:
In the first 10 years of the rclone project we received about 20 security disclosures through GitHub. We had to deal with over 40 in the last month!
About 75% of them, he says, have a nugget of something that needs looking at —
so this is not the slop wave everyone braced for, it is worse. It is real work.
And the machinery behind it has not kept up: GitHub's CVE assignments went from
2–3 days to 3–4 weeks, so he is shipping point releases with CVE-PENDING in
the changelog. He is holding a dozen independent fixes on branches and
considering merging straight to master to stay sane, which is exactly the
process erosion you would predict from load rather than from carelessness.
That is the whole story, on both sides of it. Generation got cheap — for finding bugs too, not just writing them. Verification did not. A May 2026 paper Madhavapeddy quotes calls the bottleneck "defender remediation throughput," and the honest version is that one unpaid person's afternoon is now the rate limiter on a supply chain, and there is no amount of agent tooling on their side that fixes that, because their scarce resource is the part that cannot be automated: deciding a fix is right, and carrying the consequences if it is not.
We spent the last year counting the CVEs going in. Nobody costed the queue coming out.