Glonce

AI agents now find security exploits within minutes of a bug rumour

securityThe Glonce editorsSimon Willison🔥79Glonce rating79Impact72Novelty68Relevance98Surprise78Players62Credibility87

Anil Madhavapeddy, a professor of computer science at Cambridge and a core maintainer of the OCaml compiler, wrote that security patches for OCaml projects are now drawing automated exploit probes almost as soon as they are shared for discussion. He said this used to take a few days, with a release within a week or two counted as a reasonable response time. Now, within about ten minutes of a patch being posted, his website was fielding probes for percent-encoded traversal sequences, which he took as evidence that automated watchers are monitoring public repositories for exactly this kind of signal. Madhavapeddy demonstrated the same speed himself, using AI coding agents to find a flaw from just a rumour of a bug. He switched to DeepSeek V4 Pro after Claude Fable refused the task; the source does not say why Claude Fable declined or what the underlying task was. He argues that this rate of discovery is incompatible with how open source projects currently handle embargoes on new security issues, and that maintainers need new processes to keep their communities safe.

rclone maintainer Nick Craig-Wood backed this up in the Hacker News comments on the post. He said rclone received about 20 security disclosures through GitHub in the project's first ten years, but had to deal with over 40 in the last month alone, a load that has consumed a large share of his time even with AI tools helping to triage reports and draft fixes for review. He noted the disclosures are not noise: about 75% of them contain a nugget of something genuinely worth investigating. He also pointed to a knock-on effect at GitHub, which assigns the CVE identifiers for these advisories: before what he called the AI apocalypse, assignment took 2 to 3 days, but it now runs 3 to 4 weeks, forcing him to ship point releases with CVE-PENDING placeholders in the changelog. The item is a link-blog post by Simon Willison, who frames both accounts as evidence that the speed of AI-assisted bug hunting has outrun the processes maintainers use to disclose and patch safely.

Key facts

  • Cambridge professor and OCaml compiler maintainer Anil Madhavapeddy says exploit probes now appear about ten minutes after a security patch is shared for discussion, versus a few days previously.
  • Madhavapeddy reproduced the effect himself with AI coding agents, switching to DeepSeek V4 Pro after Claude Fable refused the task.
  • rclone maintainer Nick Craig-Wood says the project received about 20 security disclosures through GitHub in its first ten years but had to handle over 40 in the last month alone.
  • About 75% of rclone's recent disclosures contain a genuine issue worth investigating, per Craig-Wood.
  • GitHub's CVE assignment time has grown from 2 to 3 days to 3 to 4 weeks, so rclone now ships point releases with CVE-PENDING in the changelog.

Why it matters

Both accounts describe the same shift from a different angle: the gap between a vulnerability becoming public knowledge and someone actively trying to exploit it has collapsed to minutes rather than days. Madhavapeddy argues this breaks the assumptions behind current embargo practices, where maintainers count on a window of days to weeks to prepare and ship a fix before disclosure. If automated watchers are probing within ten minutes of a patch being posted for discussion, that window may no longer exist in practice.

Who it affects

Open source maintainers bear the direct cost, and the examples here are from two specific, named projects: OCaml compiler infrastructure and rclone, a widely used file-sync tool. Craig-Wood's numbers show the load concentrating on unpaid or lightly resourced maintainers, who are absorbing disclosure volume that jumped from about 20 across the project's first ten years to over 40 in a single month. The slower CVE turnaround at GitHub adds a second bottleneck downstream of triage.

How to use it

There is no product or release to adopt here. The practical takeaways are process changes: treat any public patch-discussion thread as effectively live to attackers rather than embargoed, and expect vendor CVE identifiers to lag behind a fix, which is why rclone now labels early point releases CVE-PENDING rather than waiting on GitHub's assignment.

How solid is it

The claims come from two named, credentialed sources speaking about their own projects: a Cambridge professor and OCaml core maintainer, and the maintainer of rclone commenting directly in the Hacker News thread. The specific figures (about 20 disclosures in ten years, over 40 in a month, about 75% with a genuine issue, CVE turnaround moving from 2 to 3 days to 3 to 4 weeks) are self-reported by the maintainers rather than independently audited, and the source gives no total count of exploit attempts or successes, only disclosure counts and Craig-Wood's own hit-rate judgment.

Risks and caveats

The source does not say why Claude Fable refused Madhavapeddy's task or what that task was, does not date Craig-Wood's Hacker News comment, and does not identify which specific OCaml project or CVE triggered the ten-minute probing example. It also does not name which coding agents Madhavapeddy used beyond DeepSeek V4 Pro and Claude Fable.

“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.”

— Anil Madhavapeddy