2026-10-11 16:37 UTC

OCaml maintainer Anil Madhavapeddy claims AI agents can turn public vulnerability clues into working exploits within minutes of a fix PR going visible (he saw matching probes in his server logs just after opening one), rendering open-source disclosure embargoes ineffective and forcing security processes to invert toward private coordination, continuous fast releases, and protocol-level revocation — whether major projects visibly adopt such inverted practices at scale (QEMU has already shortened embargoes, rclone reports 40+ CVEs a month) or embargo-based disclosure stands resolves whether this is a live rework of OSS security or one maintainer's alarm.

state: corroboratedheat: mediumuncertainty: mediumconvergesscott: highagentic-security vulnerability-disclosure open-source-maintainershipAnil MadhavapeddyNick Craig-Wood

What is this?

OCaml maintainer and Cambridge professor Anil Madhavapeddy published a first-hand account ('Just a rumour of a bug is enough to find a security exploit these days') describing exploit probes in his webserver logs matching the exact pattern of a path-traversal bug minutes after he opened the public fix PR for cohttp 6.3.0 — before any advisory existed. His argument: AI agents can now reconstruct working exploits from fragmentary public clues alone (a PR title, an odd commit on an orphan branch, a mailing-list question), so embargo-based disclosure no longer buys maintainers time, and OSS security processes must invert toward private coordination, fast continuous releases, and protocol-level revocable capabilities. Coverage amplifying the post adds corroborating voices: rclone maintainer Nick Craig-Wood reports 40+ security disclosures in a single month (vs ~20 in the project's first decade — note: disclosures, not confirmed CVEs), QEMU has already shortened its embargo windows, Chainguard's Adrian Mouat warns projects may be forced to ship binaries before publishing source, and a study attributed to Vulncheck (cited secondhand) found an LLM agent exploited 87% of vulnerabilities given only the CVE description versus 7% without. Simon Willison and other high-profile voices boosted the post, so the claim is circulating well beyond the OCaml niche.

Why it matters to Scott

A credible maintainer with first-party log evidence has publicly arrived at the premise of Scott's Breach Doesn't Compose (AI-assisted attackers collapse time-based defenses — breach probability set by attacker search budget) and at his Capability Tokens prescription (bounded, time-limited, revocable capabilities) — a dated-receipts publishing opportunity to show the disclosure-process inversion was already argued in his canon, and Scott's non-transitive-breach architecture goes further than Madhavapeddy's process fix. It also bears on his own surfaces: work:project.wordpress-org plugin releases and the dev:project.wordpress-security-review retained-plugin estate now sit in a fix-visibility window measured in minutes, not embargo weeks.
ip:source.breach-doesnt-compose-ebookip:concept.capability-tokensdev:project.wordpress-security-reviewwork:project.wordpress-orgradar:ai-vuln-reports-oss-disclosureradar:rails-cve-hours-to-exploitationradar:exploitgym-agent-exploitation-validationradar:cve-bench-agent-exploitation
queries asked of Scott's wikis
  • agentic exploit generation LLM vulnerability discovery offensive capability
  • responsible disclosure embargo security release process open source
  • maintainer triage flood AI-generated security reports
  • capability revocation short-lived credentials token rotation protocol security
  • agent harness monitoring public signals PR watcher automation
  • continuous release cadence fast shipping security patching

Measured heat

now 0 pts/hpeak 9 pts/hcomments 0/hpeers p14momentum: steady2 platformsage 150h
points/hour across evidence · reading as of 2026-10-12 02:59:37.977291+11:00 · deterministic, not a model opinion

How the heat travelled

10-05 10:25 (minted)⭐ origin echo-reconstructedArgues AI agents can turn publicly available clues — the fix PR itself, an odd commit in an orphan branch, a mailing-list question — into wo
Anil Madhavapeddy on blog (echo) · attributed from hn.story.49962560 · published time unknown
—
10-05 09:31first on hacker news · published · lag ?AI Agents Are Disrupting Open Source Security Disclosure
amouat
—
10-05 09:31amplified on hacker newshn.story.49962560
amouat
peak 1 · 0 comments · 21% of case engagement
10-06 08:57amplified on hacker news 👑hn.story.49975981
CrankyBear
peak 4 · 0 comments · 79% of case engagement
10-05 10:20our radar first saw it · lag ?discovery anchor: hn.story.49962560—
pace: p37 vs 1247 stories at the 96h mark (now 150h old) — ahead of agentgate-signed-agent-receipts (1.3x), behind acs-local-skill-risk-catalog (0.8x)

Evidence (3) — ⭐ canonical anchor

sourceobjectauthorscorecomments
🟧 hnAI Agents Are Disrupting Open Source Security Disclosure
Retrieved article excerpt

Open article · Retrieved 2026-10-05T10:24:13.394841+00:00

[InfoQ Homepage](https://www.infoq.com/ "InfoQ Homepage")
[News](https://www.infoq.com/news "News")
AI Agents Are Disrupting Open Source Security Disclosure

[Development](https://www.infoq.com/development/ "Development")

[InfoQ Certified AI-Assisted Engineering Program (online, Oct 19): Build the harness that holds.](https://certification.qconferences.com/ai-assisted-engineering?utm_source=infoq&utm_medium=referral&utm_campaign=infoqyellowbox_onlinecohortaiassistedengineering26 )

# AI Agents Are Disrupting Open Source Security Disclosure

Oct 03, 2026
2
min read

by

- [Renato Losio](https://www.infoq.com/profile/Renato-Losio/)

#### Follow us on

[Youtube232K Followers](https://bit.ly/4bg6QM8)
[Linkedin26K Followers](https://bit.ly/44IzAtf)
[InstagramNew](https://bit.ly/4eYXrtM)
[RSS19K Readers](https://bit.ly/3RaJalC)
[X57.1k Followers](https://bit.ly/4pfxivv)
[Facebook21K Likes](https://bit.ly/3QrGMH2)
[BlueskyNew](https://bit.ly/4eS8FjG)

Listen to this article -  0:00

Audio ready to play

Your browser does not support the audio element.

0:000:00

Normal1.25x1.5x

Like

- [Reading list](https://www.infoq.com/showbookmarks.action)

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.

## About the Author

#### **Renato Losio**

Show moreShow less

#### This content is in the [AI coding agents](https://www.infoq.com/ai-coding-agents/) topic

##### Related Topics:

- [Development](https://www.infoq.com/development/)
- [Architecture & Design](https://www.infoq.com/architecture-design/)
- [Common Vulnerabilities and Exposures](https://www.infoq.com/common-vulnerabilities-and-exposures/)
- [Agents](https://www.infoq.com/Agents/)
- [Application Security](https://www.infoq.com/applicationSecurity/)
- [AI coding agents](https://www.infoq.com/ai-coding-agents/)
- [AI Security](https://www.infoq.com/ai-security/)
- [Open Source](https://www.infoq.com/opensource/)




- #### Related Editorial
- #### Related Sponsors
- #### Related Sponsor

  [Related sponsor icon](https://www.infoq.com/url/f/19e0342a-c319-45e8-a096-68d04e7ac055/)

  - October 29, 2026, 1 PM EDT

    ##### [From Tokens to Features: Architecting Cost Attribution for AI-Assisted Engineering](https://www.infoq.com/url/f/37766b8a-e117-471a-a61f-a61696a39baf/)

    [Presented by: Martin Reynolds - Field CTO at Harness](https://www.infoq.com/url/f/8cbca51d-6b08-4bf2-9b5a-da2958a15695/)

### **The InfoQ** Newsletter

A round-up of last week’s content on InfoQ sent out every Tuesday. Join a community of over 250,000 senior developers.
[View an example](https://assets.infoq.com/newsletter/regular/en/newsletter_sample/newsletter_sample.html)

[We protect your privacy.](https://www.infoq.com/privacy-notice/)
amouat10
🟧 echo.blog ⭐Argues AI agents can turn publicly available clues — the fix PR itself, an odd commit in an orphan branch, a mailing-list question — into woAnil Madhavapeddy——
🟧 hnGitHub Slams the Brakes on Private Vulnerability ReportsCrankyBear40

Interpretation history

Decision trace