AI Agents Are Disrupting Open Source Security Disclosure Cambridge computer science professor and OCaml compiler core maintainer Anil Madhavapeddy reported that AI agents can convert public vulnerability clues into working exploits within minutes, citing a study in which a GPT-4 agent exploited 87% of vulnerabilities in a 15-vulnerability benchmark when given CVE descriptions versus 7% without them. Madhavapeddy said he saw probes in his live webserver logs matching the exact bug pattern minutes after opening a pull request to fix a path-traversal flaw, and proposed private vulnerability discussions, faster continuous releases, and rapid protocol-level mitigations such as short-lived credentials and revocable capabilities. rclone creator Nick Craig-Wood said the project handled over 40 security disclosures in the last month versus about 20 in its first 10 years, and QEMU has shortened its vulnerability embargoes in response to increasingly automated discovery. A recent article by Anil Madhavapeddy argues that AI agents can turn publicly available clues about software vulnerabilities into working exploits https://anil.recoil.org/notes/rumour-is-the-exploit , reducing the effectiveness of traditional disclosure embargoes in open source projects. The author highlights the need for faster patching and release processes as the time between vulnerability disclosure and exploitation shrinks. Describing his experience fixing a path-traversal vulnerability, Madhavapeddy https://www.linkedin.com/in/anilmadhavapeddy/ , professor of computer science at Cambridge and core maintainer of the OCaml compiler, writes: The patch itself was straightforward and in normal times, the security procedure would have been to fix it privately, inform affected users, and then issue a public advisory. This time around though, I noticed probes in my live webserver logs with the exact bug pattern just minutes after opening the PR to fix the issue. Traditional security processes rely on embargoing vulnerabilities, assuming that keeping technical details secret protects users. However, AI agents can independently research vulnerabilities from limited clues: in a recent study https://arxiv.org/abs/2404.08144 , a GPT-4 agent exploited 87% of vulnerabilities in a 15-vulnerability benchmark when given CVE descriptions, compared with 7% without them. Arguing that" bugonomics https://arxiv.org/abs/2605.24632 " are now against OSS maintainers, Madhavapeddy adds: It looks to me like our security processes need to invert somewhat, since just one person searching for the issue class this could be a mailing list question, an odd commit in an orphan branch, or a context leak is sufficient to alert someone else's agent and let them get exploit code. This is wild. Adrian Mouat, developer relations at Chainguard, says that this puts open-source maintainers in a difficult position https://www.linkedin.com/posts/adrianmouat this-week-i-read-a-blog-post-by-anil-madhavapeddy-activity-7501654340584071169-5MbX/ : Just opening a PR to fix an issue puts the project and users in a bad place, as attackers can create and start using exploits even before an updated release is available. Users are put at risk and have nothing they can do about it. This may force projects to start publishing releases before the associated source code. But that breaks the fundamentals of Open Source. Madhavapeddy suggests three possible approaches to alleviate the impact before full patches are available: private vulnerability discussions, faster continuous releases, and rapid protocol-level mitigations. In a popular Hacker News thread https://news.ycombinator.com/item?id=49480466 , Nick Craig-Wood https://github.com/ncw/ , creator and maintainer of the open source rclone project, highlights the growing number of CVEs: 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 That has taken a huge amount of my time, even using AI tools to triage and come up with fixes for review. While private vulnerability coordination and faster release cycles can be implemented within existing workflows, building protocols with revocation and capability controls requires architectural changes to disable or constrain vulnerable operations remotely. Madhavapeddy suggests mechanisms such as short-lived credentials, revocable capabilities, and protocol-level controls that can be activated without requiring every client to upgrade immediately. Madhavapeddy and Craig-Wood are not the only open source maintainers raising concerns about the changing security landscape, with QEMU shortening vulnerability embargoes https://www.qemu.org/contribute/security-process/ to account for increasingly rapid and automated discovery.