AI agents shrink the time between bug and exploit in open source

A recent study shows an AI agent exploiting up to 87% of vulnerabilities using only the CVE description, and the maintainer of the OCaml compiler reports attack probes minutes after opening the patch PR, while rclone saw the volume of security disclosures spike within weeks.

What happened

An article by researcher Anil Madhavapeddy, a computer science professor at Cambridge and maintainer of the OCaml compiler, is circulating among open source project maintainers with a direct warning: AI agents can turn public clues about a vulnerability into a working exploit, and this is undermining the effectiveness of traditional disclosure embargoes. The case was reported by InfoQ on October 3, 2026.

The classic responsible disclosure model works like this: the maintainer fixes the flaw in secret, privately notifies affected users, and only then publishes a public advisory, usually with an associated CVE. This safety window is what Madhavapeddy says is collapsing.

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.

Anil Madhavapeddy, computer science professor at Cambridge and maintainer of the OCaml compiler

A study with worrying numbers

Madhavapeddy's personal experience is backed by data. A recent study he cites tested a GPT-4-based agent against a benchmark of 15 known vulnerabilities: when the agent was given the corresponding CVE description, it managed to exploit 87% of the flaws. Without that description, the success rate dropped to 7%.

The finding matters because it is precisely the CVE description, the security changelog, or even the fix PR itself that now serve as the missing trigger for the agent. In other words, the advisory meant to protect the user has also become the most effective training material for the automated attacker.

"Bugonomics": the economics of bugs turned against the maintainer

Madhavapeddy uses the term "bugonomics" to describe this inversion of cost-benefit: before, finding and exploiting a vulnerability required time and expertise from a human attacker; now, a minimal public signal is enough for an AI agent to do the heavy lifting in minutes.

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.

Anil Madhavapeddy

rclone felt the volume firsthand

In a popular Hacker News thread mentioned by InfoQ, Nick Craig-Wood, creator and maintainer of the rclone project (an open source cloud file sync tool used by many people here in Brazil for backup and integration with object storage), gave concrete numbers on the increased workload.

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.

Nick Craig-Wood, creator and maintainer of the rclone project

The jump from 20 disclosures in a decade to 40 in thirty days illustrates the new volume of work falling on maintainers who, in most open source projects, are not paid for that work.

The dilemma: fixing in public becomes arming the attacker

Adrian Mouat, from developer relations at Chainguard, sums up the impasse this creates for open source maintainers: the very act of fixing something publicly, the essence of the open source model, has become a risk.

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.

Adrian Mouat, developer relations at Chainguard

Madhavapeddy proposes three paths to reduce the damage while a full patch is not yet out:

• Private vulnerability discussions before any public commit, something already common practice in larger projects but rare in smaller libraries maintained by just a few people;
• Continuous, faster release cycles, shortening the window between merging the fix and it reaching the people who use the package;
• Protocol-level mitigations, such as short-lived credentials, revocable capabilities, and controls that can be activated remotely without requiring every client to update the software immediately.

The first two fit within the workflow most maintainers already use. The third is the hardest: it requires an architectural change to allow disabling or restricting vulnerable operations remotely, something most existing libraries and protocols simply were not designed to do.

QEMU has already reacted

InfoQ cites the QEMU project, the virtual machine emulator used as the basis for much of cloud virtualization infrastructure, as an example of a project that has already shortened its vulnerability embargo timelines precisely to keep up with this increasingly fast and automated discovery process. It is a sign that an institutional response to this problem is already underway in at least one piece of critical infrastructure.

What changes for those who maintain or depend on libraries here

If you maintain an open source project, even a small one, the calculation has changed: opening a security PR without prior coordination can itself be the trigger for an attack. It is worth considering private disclosure channels before any visible commit, and negotiating an out-of-band notice with critical users.

If you depend on third-party libraries in production, the practical lesson is to shorten your own reaction window: teams that still update dependencies manually, on monthly or quarterly cycles, are competing against agents that exploit a flaw within minutes. Automating the merge of security patches with Dependabot or Renovate, monitoring GitHub advisories in real time, and isolating exposed services with short-lived credentials stop being optional best practices and become real risk mitigation.

What remains open, according to InfoQ itself, is whether the responsible disclosure model can survive without giving up the transparency that underpins open source, or whether projects will actually shift to publishing releases before the source code, as Mouat fears. None of the three mitigations Madhavapeddy proposes solves the problem on its own, and the protocol-level control architecture does not yet exist ready-made for most ecosystems.