The window between disclosing a security bug and someone weaponizing it has collapsed to about ten minutes. That’s the alarming signal from a new post by Cambridge computer science professor Anil Madhavapeddy, flagged and analyzed by Simon Willison. Madhavapeddy maintains the OCaml compiler, and according to Simon Willison, he’s watching automated agents probe for exploits almost the instant a patch hits a public repo for discussion.
The old rhythm is gone. A fix used to take a few days to shape, with a release landing a week or two later. Now, within roughly ten minutes of posting, Madhavapeddy’s site was already fielding probes for percent-encoded path traversal sequences. Automated watchers are camped on public repositories, and modern coding agents are good enough that a hint of a bug is enough for them to reconstruct it.
What stands out here is the demonstration. Madhavapeddy reproduced the attack himself using his own agents, switching to DeepSeek V4 Pro when Claude Fable refused the task. So this isn’t a hypothetical. The same tools defenders use to triage bugs are the ones attackers point at fresh commits.
The flood is already here
This isn’t one professor’s bad week. rclone maintainer Nick Craig-Wood confirmed the pattern in the Hacker News comments, and his numbers are stark:
- In rclone’s first 10 years, the project received about 20 security disclosures through GitHub.
- Last month alone, it dealt with over 40.
- Roughly 75% of those disclosures contained a real nugget worth fixing.
That last figure matters. This isn’t just AI-generated spam clogging the inbox. Three out of four reports point at something genuine, which means maintainers can’t just filter them out. They have to read every one.
The bottleneck is spreading downstream too. Craig-Wood notes that GitHub used to assign CVE identifiers in 2-3 days. Now it’s running 3-4 weeks, so he’s shipping point releases marked “CVE-PENDING” in the changelog. The tracking system that’s supposed to keep everyone informed is falling behind the pace of discovery.
Why the old playbook breaks
Open source security has always leaned on a quiet embargo. You privately coordinate a fix, discuss it among trusted maintainers, then release the patch and disclosure together so defenders get a head start on attackers.
That model assumed humans move faster than the threat. When an exploit can materialize ten minutes after a public hint, the head start evaporates. As Simon Willison relays from Madhavapeddy, this rate of discovery looks flatly incompatible with existing embargo practices. The discussion itself, the thing maintainers need to build a good fix, becomes the leak.
This is the deeper shift. AI didn’t just speed up attackers. It erased the asymmetry that made responsible disclosure work in the first place.
What to do now
If you maintain or depend on open source, a few moves make sense over the next year:
- Move sensitive bug discussion off public repos. Use private security advisories and coordinated channels before anything touches a public issue or PR.
- Budget for triage load. Maintainers should expect disclosure volume to multiply, and 75% of it to be real. Solo maintainers will feel this first and hardest.
- Use AI on defense, deliberately. Craig-Wood is already using AI tools to triage and draft fixes for review. That’s now table stakes, not an edge.
- Don’t wait on CVE assignment. With turnaround stretching to weeks, plan releases and comms around “CVE-PENDING” rather than blocking on the identifier.
- Pressure the infrastructure. GitHub and CVE authorities need to scale assignment throughput, or the tracking layer stops being useful.
The next 12 to 24 months will force the open source world to rewrite its disclosure norms from scratch. Expect more private-by-default workflows, more automated triage, and hard conversations about how small teams survive the volume. The tools that broke the embargo aren’t going away, so the process has to change instead.
More details, including Madhavapeddy’s full write-up, are available at the original source.