Skip to content

Build1 publisher2 min readPublished

Probes hit a maintainer's webserver ten minutes after his fix PR went public

Anil Madhavapeddy's account of the cohttp 6.3.0 path traversal fix puts a number on the gap between publishing a patch and being probed for the bug it closes. The three alternatives he examined each cost a small maintainer something.

The Engineer · Build desk

Illustration accompanying Probes hit a maintainer's webserver ten minutes after his fix PR went public

What happened

  • Anil Madhavapeddy opened a pull request with a path traversal fix for OCaml's cohttp 6.3.0, and within ten minutes probes carrying the exact bug pattern were hitting his webserver.
  • The tl;dr sec write-up argues that a rumour of a bug is now enough for an agent to find it, so mean time to exploit has gone negative and exploitation arrives before the patch.
  • Madhavapeddy examines three responses and rejects each one: private forks lose CI, Chrome-style continuous shipping assumes a single binary, and protocol-layer mitigation assumes a CDN.

Compiled by The EngineerSomething wrong?How this is made

Why it matters

  • constraint A maintainer who hides the patch in a temporary private fork is preparing a security fix without the test suite that normally gates it, so the choice is early exposure or an untested patch.
  • decision A defence that depends on model refusal has to assume the whole market refuses; in this case the block on one model cost the exploit writer under a minute of switching.
  • exposure Maintainers of libraries vendored into products they do not control cannot borrow Chrome's fast-update answer, and they have no channel to push a fix past the products holding the old copy.
  • precedent If the public fix PR is itself the disclosure, embargo is being asked to keep a secret that the diff gives away, and disclosure sequencing rather than patch speed is what has to change.

Ten minutes is about how long it takes to read a diff and spot the check that was missing. It was also the gap between the pull request opening and probes carrying the exact bug pattern arriving at Madhavapeddy's webserver [2]. Generating the exploit is not what fills that gap. In his own attempt, DeepSeek V4 Pro wrote it in under a minute from only a vague description [3]. Subtract that and roughly nine minutes cover everything else: seeing the PR, reading it, pointing a model at the right function, aiming the probe [12].

Two separate observations sit behind the story. One is the probe traffic. The other is his own reproduction with a model. The tl;dr sec item does not identify who sent the probes or what tooling they used, so the chain from model to probe is inferred [13].

He pointed his own Claude at the code, Fable refused over its security block, and DeepSeek V4 Pro wrote the exploit instead [3].

Coordinated disclosure prices secrecy as time: the bug stays quiet until the fix ships [4]. Madhavapeddy's argument, as the newsletter relays it, is that a rumour alone now hands an agent enough to find the flaw, so mean time to exploit has gone negative and exploitation precedes the patch [5].

He lists three ways out and finds a flaw in each [9]. GitHub's temporary private forks let you hide the patch, but they cut you off from CI [6]. Continuous shipping works for Chrome because Chrome is a single binary, not a library buried in a hundred products nobody controls [7]. Cloud providers can slam mitigations in at the protocol layer, and open source has no CDN to carry the same rules [8].

Whether ten minutes is your number depends on the bug. Path traversal in an HTTP library is legible from the diff, reachable over the network, and needs no environment-specific setup. All three had to hold for the exploit to be a one-minute job [3]. I would not expect the same window for a use-after-free behind an allocator, and this is one maintainer reporting on one library. The interval under pressure comes before any remediation deadline: it is the order in which the fix and the knowledge become public.

"Within 10 minutes is insane," tl;dr sec wrote [10], predicting that the problem "is and will continue to be an important area of security, and may hit hard over the next few months" [11].

What to watch

  • Whether anyone publishes probe telemetry that ties a matching payload to a model-written exploit.
  • Whether GitHub wires CI into temporary private forks, the specific reason Madhavapeddy rejects them.
  • Whether OCaml or other package ecosystems change embargo practice for network-facing library bugs after this.
Loading claim ledger
Loading source directory links
Loading share composer
Loading topic controls
Loading related stories