Mean Time to Exploit Is Negative Seven Days. Your Fix PR Is the Disclosure.

Mandiant says attackers are arriving before the patch. A path-traversal bug in OCaml's cohttp shows exactly how that happens, and what a six-day public fix window costs you.

Mandiant's M-Trends 2026 puts the mean time to exploit at an estimated negative seven days. Not seven days after the patch. Seven days before it.

Read that as a sentence about arithmetic and it sounds like a rounding artifact. Read it as a sentence about process and it says the thing everybody in security has been circling for two years: exploitation now routinely precedes the fix, which means the patch is no longer the starting gun. Something else is. Google grounded that figure in more than 500,000 hours of frontline investigation across 2025, and it sits alongside a second number in the same report that explains the mechanism better than the first one does. The window between initial access and hand-off to whoever monetizes it collapsed from more than eight hours in 2022 to twenty-two seconds in 2025.

For scale, Mandiant's own earlier series tracked time-to-exploit at 63 days across 2018 and 2019, 44 days into early 2021, 32 days through 2022, and five days in 2023. The trend line was already ugly. It has since gone through the floor.

So if the patch release is not the trigger, what is? A bug in OCaml's HTTP library answered that question this month, on a public timeline anyone can check.

The six days nobody is counting

OSEC-2026-16 is a path traversal in Cohttp.Path.resolve_local_file, rated 8.7 High on CVSS v4. The cause is small and the kind of thing a careful reviewer misses: the URI path gets normalized before it gets percent-decoded, so an encoded slash survives dot-segment removal and reassembles afterward. A request to /static/..%2f..%2f..%2fetc/passwd walks straight out of your static directory. Everything below cohttp 6.3.0 is affected. The Eio bindings are not, because they resolve paths separately.

Here is the timeline the advisory itself publishes. Reported to security@ocaml.org on August 11. Fix PR opened publicly on August 14. Version 6.3.0 released August 20.

Six days. A public pull request titled "urldecode before resolving path components for files" sat open for six days, in a repository anyone can watch, describing the bug class in the title and the exact fix in the diff, while every deployed copy of the library stayed vulnerable.

Anil Madhavapeddy, who maintains the library and reviewed that fix, wrote up what happened next on August 22. He reports that within roughly ten minutes his own server started fielding probes for percent-encoded traversal sequences, which he attributes to automated watchers on public repositories. He also reports that an agent built a working exploit against a local server in under a minute. That claim is his, from his own logs, and he publishes no packet captures with it, so take it as a maintainer's account rather than a measured result. It is still the most specific public account of the loop I have read.

The loop is the point. Watch public repositories for security-shaped commits. Read the diff. Infer the bug from the fix. Generate the exploit. None of those steps needs a human anymore, and the last one used to be the expensive part.

Coordinated disclosure had one asset and it was time

The whole architecture of responsible disclosure rests on an assumption that a defender gets a head start. Report privately, fix in private, ship the release, then publish the advisory once users have somewhere to upgrade to. The embargo buys the fix time to propagate before the details go public.

That model does not fail because researchers stopped honoring embargoes. It fails because the fix itself leaks the vulnerability, and reading a diff has gotten cheap enough that the leak is now automated. The embargo protected the description of the bug. Nobody was protecting the patch, because for twenty years reverse-engineering a patch into an exploit was skilled work that took days.

I want to be careful about what I am claiming here. Patch diffing is not new, and serious attackers have done it against Windows and Chrome for a very long time. What changed is the floor. It used to be worth doing against high-value targets by people with the skills. Now it appears to be worth doing against an OCaml HTTP library by a script, and the OCaml HTTP library is in somebody's dependency tree.

The second half of Madhavapeddy's post is the part that should bother you more. He describes asking a frontier model to help build the exploit and being refused, because the security-capable tier is gated and he does not hold access to it. Anthropic's Project Glasswing is the gate he means. It launched in early April with roughly fifty partners, who between them turned up more than ten thousand high or critical severity flaws, and in June it expanded by about 150 more organizations across more than fifteen countries. Entry requires meeting Anthropic's security requirements. OpenAI drew a similar line on August 7, saying its evaluations of an upcoming model could not rule out the Critical cybersecurity threshold under its Preparedness Framework, a tier it defines as developing functional zero-days in many hardened real-world systems without human intervention.

Every one of those gates exists for a reason I would defend in an argument. Add them up anyway and you get an asymmetry that runs the wrong direction. The volunteer maintaining the library that half your stack imports cannot clear an enterprise security-requirements bar, so the tooling that would let them find their own path traversal before a stranger does is the tooling they cannot get. Madhavapeddy reports that a different model answered the same question without complaint. Gates that only some models honor are not gates. They are a tax on whoever follows the rules.

Put this into practice

The fix here is boring and mostly costs you scheduling discipline, not money. If you maintain anything with users:

1. Stop opening security fixes as public PRs. GitHub's private vulnerability reporting gives you a temporary private fork attached to the advisory draft. Do the work there. Yes, your CI will be worse in a private fork, and that is the actual cost of the change.
2. If the fix must land in the open, compress the window to hours. Not days. cohttp's six-day gap was normal practice and normal practice is now the exposure. Merge and cut the release in the same sitting.
3. Write the commit message like an attacker will read it first, because they will. "urldecode before resolving path components" is a complete bug report. A neutral message plus a detailed advisory published at release time gives up nothing to users and hands nothing to a watcher.
4. Grep your own logs for the bug pattern during the window, not after the advisory. If probes really do arrive in minutes, your access log is the earliest evidence you will get that somebody read your diff. You want that signal while you can still act on it.
5. Ship on the advisory ID you can get. OSEC-2026-16 has no CVE and never needed one. In the Hacker News thread on Madhavapeddy's post, rclone's maintainer described GitHub CVE assignment stretching from two or three days to three or four weeks, and shipping point releases with CVE-PENDING in the changelog rather than waiting. Do that. A numbering delay is not a release blocker.

If you consume libraries rather than maintain them, the change is smaller: subscribe to the ecosystem advisory database rather than waiting on CVE feeds. OSV had OSEC-2026-16 on August 20 with no CVE attached, which means a CVE-only pipeline would have shown you nothing at all.

Where this argument is weaker than it sounds

The negative-seven-days figure is a mean across the vulnerabilities Mandiant investigated during incident response in 2025. That population is selected for being worth attacking. It does not say your library gets exploited before you patch it; it says that among bugs that got exploited, arrival before the patch is now the average case. Those are different claims and the second one is the honest one.

The ten-minute probe timing is one maintainer's log reading, self-reported, on infrastructure he owns. I have no way to check it and neither do you. It is consistent with the rest of the picture, which is why I lead with it, and it is not evidence in the way the Mandiant sample is.

Private-fork development also genuinely breaks things. Small projects with volunteer reviewers lose the review quality that a public PR attracts, and Madhavapeddy's fix picked up review comments from three separate maintainers in the open. Trading that away is a real cost, not a free win, and for some projects it will be the wrong trade.

One more caveat I keep seeing repeated wrong: the claim that time-to-exploit crossed zero in 2024. I went looking for that in Google and Mandiant's own publications and could not find it. It circulates in commentary. The negative-seven figure for 2025 is documented. The crossing point is not.

What I would actually watch next

The interesting question is not whether patch-watching automation gets better. It will. The question is what maintainers do when the honest advice becomes "develop your security fixes in private," because open development is the thing most of these projects were built on and a lot of maintainers will refuse on principle.

There is a version of the next two years where the norm flips and security work routinely happens behind a curtain, and the open repository becomes the place fixes appear rather than the place they get made. That is a real loss and I do not have a clean answer to it.

If you maintain something and you have already changed your process because of this, I want to hear what broke. My guess is CI, every time.

Sources: M-Trends 2026, Google Cloud; Time-to-Exploit Trends, Mandiant; OSEC-2026-16 advisory, OSV; ocaml-cohttp PR #1145; Anil Madhavapeddy on the cohttp fix; Expanding Project Glasswing, Anthropic; Responding to the next frontier of critical cyber capabilities, OpenAI.