cohttp security patch drew exploit probes within 10 minutes

Key facts

• cohttp 6.3.0 patched a path traversal bug; about ten minutes after the fix PR went public, the maintainer's live server logged probes matching the exact bug pattern.
• Pointed at the vulnerable code with only a vague description, the maintainer's own AI agent built a working exploit against a local server in under a minute; Claude Fable refused the task outright over a security block since the maintainer lacks Project Glasswing access, while DeepSeek V4 Pro complied and found further related issues.
• A cited study (Fang et al.) found a GPT-4 agent exploited 87% of a 15-vulnerability benchmark when given a CVE description, versus 7% without one.
• The mean time to exploit has gone from about 63 days in 2018-19 to negative 7 days today, crossing zero in 2024, meaning exploitation now on average precedes the patch; marimo's CVE-2026-39987 saw its first exploit attempt 9 hours after advisory with no public proof of concept ever existing, and Langflow's CVE-2026-33017 was hit within 20 hours.
• Project Glasswing, a restricted frontier-model access program, has expanded to 150 organisations across 15 countries, but the maintainer says smaller open-source maintainers still have no access.

Why it matters

Conventional OSS security process assumes that keeping a bug's details secret buys time to patch quietly before anyone can exploit it. This account argues that assumption is breaking down: an AI agent needs only a rumour, a broad hint of where to look, not a full technical writeup, to search out and build a working exploit on its own. Pointed at the affected code with only a vague description of the bug class, the maintainer's own agent built a working exploit against a local server in under a minute; about ten minutes after the actual fix went public, the maintainer's live server was already fielding probes matching the exact bug pattern. A cited study found that giving an AI agent a full CVE description raised its exploit success rate on a benchmark from 7% to 87%, and the mean time between a patch shipping and first exploitation has gone from about 63 days in 2018-19 to negative 7 days now, a threshold it first crossed in 2024, meaning exploitation on average precedes the patch itself.

Who it affects

The immediate case is cohttp, an OCaml HTTP library, and the people who worked on its patch: the reporter who found and guided the fix, three reviewers, and an advisory coordinator. The argument is framed as a problem for open-source maintainers generally, especially smaller or volunteer-run projects that lack access to frontier AI models. Project Glasswing, a restricted program giving vetted organisations access to frontier models for defensive work, has grown to 150 organisations across 15 countries, including critical infrastructure operators, cloud and financial providers and the Linux Foundation, but leaves out what the maintainer calls mom and pop maintainers, the author's own OCaml project among them. Two other cases are cited as evidence the pattern is not isolated: marimo's CVE-2026-39987, whose first exploitation attempt came 9 hours after the advisory despite no public proof of concept ever existing, and Langflow's CVE-2026-33017, exploited within 20 hours.

How to use it

The piece is an argument with proposals rather than a tool, laying out three directions. First, develop patches somewhere genuinely private: GitHub's temporary private forks fall short in the maintainer's account because connected CI cannot access them, only a single pull request can merge into a fork, and reviewers must be enrolled one at a time by an admin. Second, stop embargoing and ship continuously and publicly instead, on the model of Chrome's two security releases a week and the Linux kernel's rule of deferring a fix at most seven days, fourteen in exceptional cases; this needs better cross-ecosystem package tracking, the subject of an upcoming ICFP talk by Ryan Gibb, plus scanning and triage tools such as Andrew Nesbitt's Scrutineer. Third, deploy protocol-layer virtual patches the moment a report arrives, as Cloudflare did with managed mitigation rules for Log4Shell in 2021, though the maintainer notes open source has no distribution channel for such rules outside a commercial CDN today.

How solid is it

The central claims rest on the maintainer's own first-hand incident, the cohttp patch and the probes that followed, plus two named, dated CVEs with cited timeframes, which gives the account concrete, checkable specifics rather than a vague alarm. The 87% versus 7% exploit-rate figure is attributed to a named study (Fang et al.) using a defined 15-vulnerability benchmark, and the bugonomics framing is credited to a specific, dated paper (Pesoli et al., May 2026) rather than presented as the maintainer's own theory. The Project Glasswing membership figures are stated as fact but not independently sourced beyond the maintainer's own account.

Risks and caveats

The source does not establish that the probes recorded ten minutes after the cohttp PR went public were actually generated by an AI agent rather than a generic automated scanner; the maintainer frames it as automated watchers without confirming the mechanism, so the link to agentic exploitation is an inference, not a demonstrated fact. The mean-time-to-exploit trend line, from 63 days to negative 7 days, is presented without a named source or methodology for how it is tracked. The piece is explicitly a first-person argument for change rather than a neutral report, and its recommendations, private development infrastructure, continuous release, protocol-layer patching, are the maintainer's own proposals rather than adopted industry practice.

“The question is not whether frontier models, open-weight models, or program analysis "win". The question is how to orchestrate them so that scarce validation, prioritization, and release capacity goes toward durable fixes rather than mechanical search and report drafting.”

— Pesoli et al., "Demystifying the Mythos or Disrupting Bugonomics?" (2026)