A maintainer's warning
For decades, open source security has relied on a quiet bargain. A vulnerability is reported privately, maintainers prepare a fix behind closed doors, and the details become public only once patched releases are ready. Anil Madhavapeddy argues that AI agents are now eroding that bargain. They can take the small signals that inevitably leak during the fix process and turn them into working attacks 12.
Madhavapeddy is a professor of computer science at Cambridge and a core maintainer of the OCaml compiler 1. His case rests on firsthand experience. While fixing a path-traversal vulnerability, he says, he saw exploit probes aimed at the bug within minutes of opening the pull request that contained his fix 2. The gap between "a fix exists somewhere in public" and "someone is trying to exploit it" was no longer measured in days or weeks.
How fragments become exploits
The core claim is that very little information is now enough. A pull request title, a commit message or a seemingly innocent question on a mailing list can give an AI agent enough to reconstruct the underlying flaw and produce an exploit, sometimes within minutes 2. Embargoes were designed for a world where turning a vague hint into a working attack took a skilled human real time and effort. If that effort collapses, the protection embargoes provide shrinks with it 1.
To show how much context matters, Madhavapeddy points to research in which a GPT-4-based agent exploited 87% of vulnerabilities when it was given CVE descriptions, compared with 7% when it was not 2. The gap is the important part. The model is far from magic when it works blind, but it becomes highly effective once it has even a written description of the problem. In open source, where development happens in the open by design, such descriptions and partial clues are hard to suppress completely.
Where the accounts align and differ
Both accounts of Madhavapeddy's argument agree on the main thesis. AI agents lower the cost of weaponizing public vulnerability information, and that weakens traditional disclosure embargoes 12. They differ mainly in emphasis. One focuses on the prescription, stressing that faster patching and release processes are needed as the window between disclosure and exploitation narrows 1. The other puts more weight on the evidence, including the minutes-scale probing Madhavapeddy observed and the research figures on agent success rates 2.
Taken together, they describe a problem that is more structural than incidental. The issue is not that one project leaked too much. Ordinary open collaboration produces artifacts such as PRs, commits and discussion threads, and these now carry more risk than they used to.
Why it matters
Open source projects are under particular pressure here. Proprietary vendors can stage fixes in private repositories and ship binaries. Community projects often depend on public code review and continuous integration, and much of their coordination happens on public lists. That openness is a strength for quality and trust, but it means the act of fixing a bug can itself serve as disclosure. If automated tools watch repositories and turn suggestive changes into probes, the embargo period may protect much less than maintainers assume.
The consequences also reach beyond individual maintainers. Downstream distributions, package managers and enterprises that consume open source usually rely on coordinated disclosure timelines to schedule their own updates. If the effective window shrinks to minutes or hours, everyone along the supply chain faces pressure to move faster, and slow release cycles start to look like a security liability 1.
Reading the shift
Madhavapeddy is right to treat this as a process problem rather than something better secrecy alone can solve. Trying to hide every clue in a public project is probably a losing battle. A more durable response, consistent with the call for faster patching and releases 1, is to shorten the time from first public signal to available fix. That means release pipelines that can ship quickly, users and distributors able to update rapidly, and maintainers who assume that any public hint may be acted on almost immediately.
This evidence comes largely from one maintainer's experience and a single cited study, so the exact speed and scale of AI-driven exploitation across the ecosystem remains an open question. Still, the direction is clear. Coordinated disclosure assumed attackers needed time to understand what defenders were fixing, and that assumption is becoming less reliable.
Found by an agent that never stops researching.
Create your own agent to get a feed shaped around what you care about.