Patch Discussion to Exploit Probe: Now Measured in Minutes, Not Days

A short post from Anil Madhavapeddy — a Cambridge computer science professor and core maintainer of the OCaml compiler — has been circulating after he described watching an exploit attempt materialise against a project of his in close to real time. According to his account, relayed by Simon Willison, the normal cadence for an open-source security fix is a few days of private discussion followed by a release within a week or two. This time, within about ten minutes of a patch being shared for public discussion — not merged, not released, just discussed — his webserver logs showed probes for percent-encoded path-traversal sequences: exactly the bug class under discussion.

That detail matters more than it might first appear. Percent-encoding a path separator (%2e%2e%2f and its variants) is a classic way to smuggle a directory-traversal payload past a naive input filter. Someone — or something — was watching the discussion closely enough to know precisely what pattern to throw at the server, and did so almost immediately.

This isn't an isolated data point

Nick Craig-Wood, maintainer of the widely used file-sync tool rclone, is cited with a similar pattern at a different scale: around 40 security disclosures landing in the last month, compared with roughly 20 across the project's entire first decade. Not all of these are equally serious, but a meaningful share are: roughly three in four reportedly contain "a nugget of something which needs looking at" rather than being pure noise.

Volume and speed are compounding at the same time — and the coordination infrastructure built for a slower era is straining under both. CVE assignment turnaround, once a matter of two to three days, is reportedly now taking three to four weeks in some cases. That's a serious problem: if the public record of "this is a real, tracked vulnerability" lags weeks behind the moment attackers start probing for it, defenders lose the one coordination signal they could previously rely on.

Why the gap is closing

None of this requires a leaked zero-day or insider access. A public GitHub PR, a mailing list thread, or an issue comment discussing a fix is, by itself, enough signal for automated tooling to go looking for the underlying flaw and start testing it against anything still unpatched. Historically, turning a vague bug rumour into a working exploit took real analyst time — reading the diff, understanding the vulnerable code path, building and testing a payload. That step is the one being compressed.

The practical effect is that "we're discussing a fix, we'll patch soon" is no longer a safe interval. If exploitation can start before the patch does, the traditional coordinated-disclosure timeline — quiet fix, then release, then advisory — no longer buys the breathing room it used to.

What this changes for defenders

• Don't wait for the CVE or the release tag to react. If a dependency's issue tracker or PR history shows an unreleased security fix in flight, treat unpatched, internet-facing instances as being under active probing risk immediately — not once an advisory lands.
• Instrument for the specific pattern being discussed, not just for "attacks in general." In this case, that meant watching for percent-encoded traversal sequences in access logs the moment the bug class was named publicly.
• Assume CVE numbering and advisory feeds are a lagging indicator right now. A 3-4 week assignment delay means your vulnerability-intel pipeline, if it's keyed off CVE publication, is structurally behind the attackers.

Nothing here points to a single new tool or technique — it's a shift in tempo. The organisations most exposed are the ones whose patch cadence and monitoring assume the old timeline still holds.