A recent article by Anil Madhavapeddy argues that AI agents can turn publicly available clues about software vulnerabilities into working exploits, 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, 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, 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" 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:
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, Nick Craig-Wood, 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 to account for increasingly rapid and automated discovery.