Frontier LLM developers tout vulnerability discovery and exploit chaining as if that were customer defense. It is not: defense needs minimized false positives, comprehensive coverage, and cost efficiency — sensors, inline inspection and enforcement, built collaboratively. Discovery must be balanced with a solve: AI-recommended patches still need environment testing; different frontier models find different vulnerabilities, so one model is not the solution; most organizations — especially smaller ones and operational technology — cannot patch at the speed needed. The obvious bridge is virtual patching, scaled fast through a vulnerability clearinghouse and rapid signature development across the industry.
This paper rests on 24 citation-ready evidence rows gathered on 5 November 2026 from 18 distinct hosts — the largest host contributes 16.7% of rows, so no single source backs more than a sliver of the argument. The rows span four pillars: frontier capability and model variance, exploit speed, AI patch reliability, and virtual patching and OT controls. Some evidence is preprint research, and some 2026 capability claims come from developer system cards or external evaluations, so findings should be revisited as models and benchmarks change.
Days since public disclosure (left to right). The red lane is how fast attackers and AI move; the green lane is how long verified, permanent remediation takes. The amber band is the virtual-patching bridge — rapid, inline, temporary protection that buys the green lane time. Hover or tap any marker for the finding and its source.
Frontier AI developers increasingly demonstrate that their models can find vulnerabilities and chain them into multi-stage attacks. That is capability disclosure, not customer defense. The evidence below shows three things at once: AI-assisted discovery and exploitation are improving materially but unevenly across models; attacker exploitation timelines are now measured in single-digit days; and AI-generated patches are not yet reliable enough for unreviewed production deployment. The structural result is a protection gap that no single enterprise — least of all a small one or an OT operator — can close alone. The responsible move for frontier developers is to feed validated findings into a collaborative, vendor-neutral clearinghouse that converts them into machine-readable detections and mitigations, with virtual patching as the explicitly temporary bridge to tested permanent remediation. The clearinghouse and the multi-model harness are policy recommendations inferred from this evidence, not already-proven comprehensive solutions.
Results are real but conditional. The UK AI Security Institute confirmed a frontier model completing a 32-step simulated corporate network attack end-to-end — succeeding in 3 of 10 attempts and averaging 22 of 32 steps versus 16 for the prior model — on a vulnerable range with no active defenders (cdn.hexaware.com). A successor model solved the same range in 8 of 10 attempts at a budget of 100M tokens per attempt, again in small ranges lacking defensive tooling and human response (www-cdn.anthropic.com). External evaluation of GPT-5.6 Sol found offensive capability on-par or slightly stronger than its predecessor — 19/197 FrontierCyber challenges solved, with continued limits against hardened targets and in orchestration and operational security (deploymentsafety.openai.com). Google DeepMind's dangerous-capability evaluation of Gemini 1.0 Ultra found component competence with chain failure on long-horizon operation, below skilled human operators — while cautioning that elicitation is imperfect and results do not bound untested scaffolds (scixa.com). Capability depends heavily on configuration: enabling reasoning mode alone moved one model's CyBench risk score from 0.0 to 5.0 and another's from 5.0 to 17.5 (arxiv.org).
Defense is a pipeline — telemetry and sensors, exploitability confirmation, detection content, inline enforcement, and finally tested permanent patches — and discovery is only its first stage. Five coverages must be kept distinct: discovery coverage (which flaws are found), exploitability confirmation (which are actually attackable), detection coverage (which attacks are seen), mitigation coverage (which are blocked inline), and permanent remediation (which are fixed at source). Publishing stronger discovery results while leaving the other four stages to each enterprise individually shifts cost downstream: every customer must re-scan, re-triage and re-patch findings the model developer already validated once. The defensible quality bar for the enforcement stages is measured, minimized, and governed false positives — not a literal promise of zero.
AI remediation helps, but validation is the bottleneck. PATCHEVAL finds LLM-as-a-Judge patch validation agrees with ground-truth dynamic testing only 76.32%–81.14% of the time, overlooking compilation and runtime errors (arxiv.org). PVBench shows over 40% of patches validated as correct by basic tests fail under stronger PoC+ testing across 209 cases in 20 projects — current success rates are significantly overestimated (mccormick.northwestern.edu). Worse, SWExploit shows repair agents can be misled into patches that are functionally correct yet vulnerable, with attack success on "correct" patches reaching 0.91 against baselines below 0.20 (arxiv.org). Even a strong result — PATCHAGENT repairing 8 of 10 previously unseen vulnerabilities — still required manual review before submission (dataisland.org). Before deployment, a patch must be tested in its environment; no enterprise can do that at exploit speed for every finding.
The capability evidence varies sharply by model, task, scaffolding, and configuration: one model completes a range end-to-end while another fails long-horizon chains; a reasoning toggle multiplies offensive scores; hardened targets defeat models that beat vulnerable ranges. Because different frontier models surface different vulnerabilities under different conditions, discovery and validation should run across a multi-model harness with independent confirmation, rather than trusting any single vendor's model — or its self-reported system card — as the coverage standard.
Median time-to-exploit has collapsed from 296 days in 2005 to six days by 2018 (discovery.researcher.life), to roughly 5 days in 2025 (labs.cloudsecurityalliance.org); Rapid7 measures 5.0 days median — down 41% year over year (captechgroup.com) — and 3 days on average for high-severity disclosures in Q3 2026 (blog.rapid7.com). CISA reports 50% of known-exploited CVEs in use within 2 days of disclosure (cisa.gov), and Cyentia/FIRST find 70% of exploited vulnerabilities see first attack activity within a year (cyentia.com). No enterprise verification-and-patch cycle runs in two days; the gap is structural, not an operational shortfall.
Operational technology needs its own lane. Maintenance windows, safety cases, availability requirements, vendor validation of firmware, legacy systems, and protocol-aware controls make ordinary IT patch cadences unsuitable — practitioners note that on DCS controllers patching may simply be unavailable within operational constraints (youtube.com). US government guidance for zero trust in OT is explicit: when patching cannot be promptly performed, shift to isolating vulnerable systems and compensating controls — increase monitoring, restrict communication pathways, or deploy virtual patches through network defenses — while maintaining operational safety and continuity (ic3.gov; see also cisa.gov and tech-champion.com). SANS work on controlled IPS deployment shows signature-based inline protection can be rolled out faster than remediation while managing false-positive risk (giac.org). Open-source components deserve the same compensating-control treatment where upstream fixes lag.
A proposed operating model — a policy recommendation inferred from the evidence above, not a proven system:
Counterarguments and limitations. Virtual patches can be evaded by variants the signature misses; they may disrupt legitimate traffic when tuned poorly; they only protect traffic visible at the enforcement point — encrypted, internal, or out-of-band paths stay exposed; and left indefinitely they become operational debt that masks unremediated risk. Virtual patching is a risk-reducing bridge, not a substitute for source remediation.
| Organization | Subject | Finding | Metric | Source |
|---|
Method: 24 citation-ready evidence rows collected 2026-11-05 from 18 distinct hosts (largest host 16.7% of rows), organized into four pillars: frontier capability and model variance, exploit speed, AI patch reliability, and virtual patching and OT controls. Metrics measure what each source reports — challenge solve counts, median or average days from disclosure to exploitation, patch-validation agreement and failure rates. Timeline chart plots only rows with day-denominated metrics; duplicate publications of the same study appear as separate rows in the table. Some evidence is preprint and some 2026 claims are developer system cards or external evaluations; revisit as models and benchmarks change. Caveats and full titles trimmed for space; follow source links for detail.