Opening the cohttp fix PR drew traversal probes within ten minutes

Madhavapeddy asked his own Claude to investigate path normalisation issues in the affected cohttp code ^[5]. He gave it no CVE text, no proof-of-concept, not even a line number. Claude Fable refused on its security block, because he has no Glasswing access, so he switched to DeepSeek V4 Pro, which independently turned up several related issues ^[6]. His agent then wrote a probe against a local live server in under a minute ^[7].

Set that against the benchmark he cites. Fang et al reported that a GPT-4 agent given a CVE description exploited 87% of a 15-vulnerability benchmark, and 7% without the description ^[10]. On 15 targets, 87% is 13 and 7% is one ^[18]. So the published gap between told-what-the-bug-is and told-nothing is twelve exploits out of fifteen, measured on a hand-picked set. For that ratio to say anything about cohttp, the no-description condition would have to resemble what Madhavapeddy actually supplied, and it does not. He gave a bug class and a file.

The process he departed from is the standard one: fix privately, inform affected users, then issue the public advisory ^[2]. He opened cohttp#1145 publicly instead, to get more eyes on it, and would normally expect a few days of review and a release within a week or two ^[8]. About ten minutes later his webserver was fielding probes for percent-encoded traversal sequences, which he reads as automated watchers keeping an eye on public repositories ^[9]. "I found I could use my own agents to find the exploit just by knowing roughly what it was about," he wrote ^[16].

And ten minutes was the delay he happened to measure: he notes that a determined attacker monitoring package repositories could be exploiting within seconds ^[17].

The trend line he cites puts mean time to exploit at -7 days now, against roughly 63 days in 2018-19, having crossed zero in 2024 ^[11]. That is a 70-day swing ^[19]. Two 2026 cases sit inside it: marimo's CVE-2026-39987 drew its first exploitation attempt 9 hours after the advisory with no public proof-of-concept in existence, and Langflow's CVE-2026-33017 took 20 hours ^[12].

The defender side has not moved at the same rate. A May 2026 paper coined the term "bugonomics" and argues the bottleneck has moved to defender remediation throughput ^[13]. Pesoli et al wrote that the point is not which of frontier models, open-weight models or program analysis comes out on top, and that the task is to orchestrate them so scarce validation, prioritization and release capacity goes toward durable fixes instead of mechanical search and report drafting ^[14]. Madhavapeddy's account from the maintainer's chair matches: exploit generation scales while validation, triage and release rates stay flat ^[15].

What the evidence does not establish is frequency. This is one repository, one maintainer's server logs, one set of probes matching one pattern, and the inference that automated tooling is watching public repos is his, drawn from the timing ^[9]. His conclusion is that security processes need to invert, because one person searching for the issue class is enough to alert someone else's agent and hand it working exploit code ^[20].