AI agents now weaponize bug rumors faster than maintainers can patch

An OCaml cohttp maintainer describes patching a path-traversal flaw in version 6.3.0 and watching automated scanners probe his live server for that exact bug within ten minutes of opening the public fix PR. Worse, he found he could point his own coding agent at the affected code and have it independently rediscover related issues and generate working exploit code in under a minute—meaning an attacker needs only a vague hint about where a bug lives to produce a functioning exploit. This collapses the assumptions behind traditional security embargoes, which depend on keeping bug details secret until users are patched.

The data backs up the anecdote: research showed a GPT-4 agent exploited 87% of a benchmark when handed the CVE description versus 7% without it, and the mean time-to-exploit has now gone negative—exploitation increasingly precedes the patch, a metric that sat around 63 days in 2018-19. Recent CVEs in projects like marimo and Langflow saw exploitation attempts within 9 to 20 hours of an advisory, even absent any public proof-of-concept. The bottleneck, per emerging ‘bugonomics’ research, has shifted to defender remediation throughput: LLMs generate exploits at scale while maintainer triage, validation, and release capacity stays flat.

Small open-source projects are hit hardest because they lack access to the guarded frontier models (Project Glasswing reaches 150 organizations but not ‘mom and pop’ maintainers), and Western commercial models block security-tooling use. The author weighs two adaptations: developing fixes in genuinely AI-inaccessible private channels—though GitHub’s temporary private forks break CI and multi-repo workflows—or abandoning embargoes entirely to ship continuously like Chrome does, with rapid automated releases and live patching. The real problem, he argues, isn’t keeping the patch secret but getting the vulnerability details to exactly the right trusted people without leaking to the automated watchers, and OSS lacks both the release automation and the web-of-trust infrastructure to do either well.