AI NewsInfrastructureReported

An OCaml maintainer saw attack probes ten minutes after opening his fix

Cambridge researcher Anil Madhavapeddy opened a pull request to fix a path traversal in OCaml cohttp 6.3.0 on 22 August. Within ten minutes, his web server was receiving percent-encoded probes for exactly that class of attack.

AI News

Editorial2 min read

LinkedInX

Why it mattersThe time between a public patch discussion and working exploits is now measured in minutes, so any team whose disclosure process assumes hours without attacks before the patch is merged has a wrong assumption.

Anil Madhavapeddy, a computer science professor at Cambridge and long-time OCaml maintainer, opened a pull request on 22 August to fix a path traversal issue in the OCaml cohttp library, version 6.3.0, filed as OSEC-2026-16. His post describes what happened next, and Simon Willison summarised it on 28 August under the title "Just a rumour of a bug is enough to find a security exploit these days."

Within about ten minutes of the pull request going public, Madhavapeddy's own web server was receiving requests probing for percent-encoded path traversal sequences, which is the exact class of bug the fix addresses. His own conclusion is that automated systems watch public commits and issue trackers, and that ten minutes was in fact slow. He tested by asking a coding agent to write an exploit from the pull request alone, and reports his own agents produced a working one in about one minute.

How the exploit was reproduced

Madhavapeddy tried several coding agents on the pull request. He reports that Claude Fable declined to help on safety grounds and that DeepSeek V4 Pro identified the traversal and related issues. His own agents wrote the working exploit locally in about a minute, from the diff and the commit message alone.

The wider numbers he cites

He refers to a VulnCheck 2026 report showing mean time to exploit at negative seven days, meaning exploitation now precedes patches on average, against a 2018 to 2019 baseline of about sixty three days. He also cites the marimo path traversal, CVE-2026-39987, exploited nine hours after the advisory, and Langflow CVE-2026-33017, compromised within twenty hours. He compares his own ten-minute observation with these numbers.

Nick Craig-Wood, who maintains rclone, told the Hacker News thread that his own security disclosures have gone from about twenty a year to more than forty a month, with about three in four containing something real. That is a Hacker News comment from one maintainer rather than a study, so read it as one data point that agrees.

The release is the disclosure

The old pattern of coordinated disclosure was that a maintainer merged the patch into main and had some useful time before attackers found the flaw. That extra time is gone for popular libraries. A public pull request titled "fix path traversal", or a commit that touches a URL parser and adds tests for percent-encoded input, is now enough for someone watching with a coding agent to write the exploit before the release notes are drafted.

The action is to treat the release as the disclosure. Keep the patch private, publish the release, get a CVE and an advisory out, then push. If your project's workflow is public by default and you cannot keep a fix private, at least do not describe the vulnerability in the commit message. And if you run an unpatched server on a widely deployed library, assume the delay between someone else's fix being published and probes reaching you is minutes.

Source

This item was written by an AI system from the linked source. Reveneau is responsible for what it publishes.

Share
LinkedInX
Start a project