On August 22, 2026, Anil Madhavapeddy, the University of Cambridge professor who wrote the OCaml cohttp library, opened a pull request fixing a path traversal bug: percent-encoded sequences like ..%2f..%2f could escape the intended document root (OCaml Discuss, 2026-08-22). Ten minutes after the PR went public, automated scanners were already hitting his server with that same traversal string (Madhavapeddy, 2026-08-22). Out of curiosity, he pointed an AI agent at a local copy of the unfixed code and asked it to build an exploit. It had a working one in under a minute.
No advisory had shipped yet. No proof-of-concept existed anywhere public. The only signal in the world was a diff and a commit message describing what the diff fixed. That was enough.
Most patch processes still run on an assumption: that there's a gap between "a fix exists" and "someone weaponizes it," and that the gap is where triage happens, a scheduling call about whether a fix ships this week or waits for the next release window. Madhavapeddy tracks a number for what that gap has become. Mean time to exploit across the industry ran about 63 days in 2018 and 2019, turned negative sometime in 2024, and by his count now sits at negative seven days: exploitation arriving before the patch does, on average (Madhavapeddy, 2026-08-22). The gap the patch process was built around isn't shrinking. It's gone negative.
The advisory already does the attacker's work
Two disclosures from this year show what that looks like against production software with real users, not a research library.
CVE-2026-39987, a pre-authentication remote code execution flaw in the Python notebook tool Marimo, went from advisory to first exploitation attempt in 9 hours and 41 minutes. The vulnerable endpoint, /terminal/ws, was simply missing the validate_auth() call every other WebSocket route in the application made, and the advisory said so directly. No public proof-of-concept existed when the first attack landed (Sysdig, 2026). CVE-2026-33017, an unauthenticated remote code execution bug in the AI pipeline builder Langflow, took about 20 hours: disclosed March 17, 2026, and under active exploitation by 16:04 UTC the next day, again with no exploit code circulating beforehand (Sysdig, 2026-03-18). CISA added it to the Known Exploited Vulnerabilities catalog eight days later.
In both cases, the advisory contained everything an agent needed to close the rest of the gap itself: the vulnerable path, the missing check, the class of bug. Nobody reverse-engineered a patch. They read a paragraph.
The skill gap already closed
This isn't a story about one gifted attacker. Fang, Bindu, Gupta, and Kang built a benchmark of 15 real vulnerabilities and found that a GPT-4 agent given the CVE description exploited 87% of them. Without the description, the same agent managed 7%, and every other model or scanner they tested, GPT-3.5, eight open-source LLMs, ZAP, Metasploit, scored 0% (Fang et al., arXiv:2404.08144, 2024). The description is nearly the entire difficulty. Once it exists, in a CVE record, a security advisory, or a public pull request titled with the word "security," writing the exploit is close to automatic.
Madhavapeddy watched the asymmetry play out on his own bug. One model, Fable, refused to investigate at all, citing a safety restriction tied to Project Glasswing, an early-access defensive research program he doesn't have a seat in. A different model, DeepSeek V4 Pro, had no such restriction, reproduced his path traversal bug, and found a handful of adjacent issues nobody had asked it to look for (Madhavapeddy, 2026-08-22). Frontier defensive access runs through Project Glasswing, a program that already covers 150 organizations in 15 countries, cloud providers and financial firms and the Linux Foundation among them, and the person maintaining the library all of them run still isn't on that list (Madhavapeddy, 2026-08-22). Defensive tooling and offensive tooling aren't gated the same way at the frontier, and the gap runs downhill to whoever is smallest.
The bottleneck was never finding the bug
A May 2026 paper on what its authors call "bugonomics" argues the real constraint moved a while ago, from whether attackers can find bugs, which is settled, to defender remediation throughput: how fast a validated fix gets triaged, tested, and shipped once it exists (Pesoli et al., arXiv:2605.24632, 2026-05). Mozilla's own disclosure volume shows the scale of the problem: 271 bugs surfaced against Firefox 150 by Anthropic's automated Mythos program alone, against 423 total security bugs fixed across every source that month (Pesoli et al., arXiv:2605.24632, 2026-05). More validated bugs are arriving than most teams can absorb, prioritize, and ship fixes for on the cadence their process was built around.
Chrome and the Linux kernel show what keeping pace actually costs. Chrome ships two security releases a week, and the kernel gives a disclosed fix at most a week before it has to ship, two in unusual cases (Madhavapeddy, 2026-08-22). Both are only possible because of infrastructure most companies never build: automatic update channels, staged rollouts, and a release team whose entire job is exactly this.
What a team without that infrastructure still has
None of that describes a 30-person company running Marimo internally, or Langflow, or a service built on cohttp. Nobody there is shipping a new binary twice a week, and nobody should try to become Chrome to solve this.
The workable version of this problem is older than AI agents. Cloudflare watched exploitation attempts against Log4Shell begin nine minutes after CVE-2021-44228's public disclosure in December 2021, well before most of the internet's Java applications were patched, and it closed the gap for its customers with WAF rules, not a code change any of those customers had to write themselves (Cloudflare, 2021-12). Virtual patching at the network layer doesn't require finding time in a sprint. It requires someone already watching the traffic who can push a rule the same hour the pattern shows up, whether that pattern follows a real advisory or, per Madhavapeddy, just a rumor of one.
That's the actual question behind vulnerability management now: not whether a scanner runs monthly, but whether anything is watching your dependencies' advisories, pull requests, and traffic closely enough to act inside the same hours an agent would use against you. If your current process treats a security PR on something in your stack as a ticket for next sprint's planning meeting, that ticket is already behind the clock the attacker is running.
Sources: Madhavapeddy, "Just a rumour of a bug is enough to find a security exploit these days", 2026-08-22; OCaml Discuss on cohttp 6.3.0 / OSEC-2026-16; Sysdig on Marimo CVE-2026-39987; GitHub Advisory GHSA-2679-6mx9-h9xc; Sysdig on Langflow CVE-2026-33017; Fang, Bindu, Gupta, and Kang, arXiv:2404.08144; Pesoli et al., arXiv:2605.24632; Cloudflare on Log4Shell exploitation timing.