For as long as open source has had security teams, the ritual has been the same. Find a bug, fix it quietly, warn the people who need to know, and only then tell the world. The secrecy was the whole point: keep the technical details embargoed long enough for a patch to reach users before an attacker can weaponise the flaw. This week a Cambridge computer scientist described watching that ritual fail in real time, and his account has set off an uncomfortable conversation among the people who maintain the software the internet runs on.
Anil Madhavapeddy, a professor and core maintainer of the OCaml compiler, was fixing a routine path-traversal bug. In normal times he would have patched it privately and published an advisory later. Instead, minutes after he opened the pull request to fix it, his webserver logs filled with probes matching the exact bug pattern. Someone, or more precisely something, had read the public fix and started hunting for the hole before a release was even out.
The mechanism is AI agents. In one study he cites, a GPT-4 agent exploited 87 percent of the vulnerabilities in a benchmark when handed the CVE descriptions, against just 7 percent without them. The clue no longer has to be a published advisory. An odd commit on an orphan branch, a mailing-list question, a leaked scrap of context: any of these is now enough for someone else's agent to reconstruct the vulnerability and generate working exploit code. Madhavapeddy calls the new economics "bugonomics," and they have turned against the defender.
The numbers maintainers are quoting are stark. Nick Craig-Wood, who runs the open-source rclone project, said he received about 20 security disclosures in the project's first ten years, and more than 40 in the last month alone. The broader signal is just as pointed: in a weekly roundup, researchers flagged Anthropic's report on the model GLM-5.3 and its claim that a cheap variant assembled a working exploit chain for $20.40. Like the 87 percent figure, that price tag is a lab claim until someone reproduces it independently. The point is the direction, not the decimal.
Here is the tension the story exposes. Open source works because fixes are public: anyone can read the code, verify the patch, and rebuild from source. But if publishing the fix is what tips off the attacker, maintainers face a genuinely ugly choice. One developer at the security firm Chainguard floated the idea of shipping releases before the source code that explains them, then immediately noted that this "breaks the fundamentals of open source."
Nobody has a clean answer. Madhavapeddy argues the security model has to invert: private vulnerability discussion, far faster and more continuous releases so a patch is ready the moment a fix becomes visible, and protocol-level defences such as short-lived credentials and revocable capabilities that can shut down a vulnerable operation remotely, without waiting for every user to upgrade. The QEMU project has already begun shortening its embargo windows to match the new pace.
What makes this more than a maintainer's complaint is who it lands on. The infrastructure most of the internet quietly depends on is kept alive by small, often unpaid teams. The same AI tooling that lets one researcher triage 40 disclosures a month is exactly what lets an attacker turn a hint into an exploit before lunch. For now, the people holding that line are asking a hard question out loud: if transparency is what gets users hurt, what is open source supposed to do instead?