Mean Time to Patch Is Shrinking: How AI Vulnerability Discovery Collapses Your Patching Window

The standard vulnerability management lifecycle has remained largely unchanged for two decades. It begins with discovery: vulnerability scanners (Qualys, Tenable, Rapid7) assess the environment on a periodic schedule, typically weekly or monthly for internal assets and continuously for internet-facing systems. Discovery outputs a raw list of CVEs present in the environment, each with a CVSS score. The second phase is triage and prioritization: security teams filter the raw CVE list by CVSS severity, asset type, and business criticality to produce a prioritized remediation queue. The third phase is remediation planning: change management processes are initiated, patch testing is scheduled, and maintenance windows are identified. The fourth phase is patch deployment: patches are applied in maintenance windows, often sequenced across environments (dev, staging, production) over multiple weeks. The fifth phase is validation: rescans confirm that patched findings are resolved. This lifecycle, when executed well, produces MTTP values of 15-30 days for critical findings and 30-60 days for high findings. These timelines were calibrated to the threat environment of the early 2010s, when the average time from CVE publication to active exploitation in commodity threat actor toolkits was measured in weeks. That calibration is now wrong.

Mean time to exploit (MTTE) is the elapsed time between a vulnerability being disclosed (or, in the Glasswing context, discovered) and a working exploit being available. Historically, MTTE depended on the vulnerability class (memory corruption vulnerabilities take longer to exploit reliably than authentication bypass or SQL injection), the skill of available researchers, and the commercial incentive to develop an exploit. For high-value vulnerabilities (critical CVSS, widely deployed software, clear monetization path), well-resourced threat actors might develop exploits within days of CVE publication. For lower-profile vulnerabilities, MTTE could extend to months or never. AI changes the MTTE calculation by automating exploit development reasoning. Claude Mythos's performance on the V8 adversarial code execution benchmark, 21 solutions out of 41 challenges with no other model above zero, demonstrates a capability that previously required elite human expertise. Exploit development that required a skilled researcher a week or two now takes Mythos minutes to hours within the same analytical context. The practical consequence is that for vulnerabilities amenable to AI-assisted exploitation (particularly memory corruption, type confusion, and control flow bugs in widely deployed software), MTTE collapses to the same session as discovery. Your 30-day patch SLA now covers a window during which a sophisticated adversary with AI tools has had a working exploit for 29 days.

CVSS (Common Vulnerability Scoring System) was designed to provide a standardized severity rating that enables comparison across vulnerability types. A CVSS 9.1 finding (like wolfSSL CVE-2026-5194) is objectively more severe than a CVSS 4.5 finding in almost all contexts. But CVSS score alone is a poor prioritization tool for two reasons. First, CVSS does not incorporate exploit availability. A CVSS 10.0 vulnerability with no publicly available exploit and no active exploitation presents a materially different risk than a CVSS 7.5 vulnerability with exploit code in Metasploit and confirmed active exploitation by ransomware groups. CISA's Known Exploited Vulnerabilities (KEV) catalog exists precisely because exploit availability is a better predictor of whether a vulnerability will be targeted than CVSS score. Research consistently shows that only a small fraction of published CVEs are ever actively exploited, and CVSS score is a weak predictor of which ones get weaponized. Second, CVSS does not incorporate asset context. A CVSS 9.0 finding on an air-gapped development server is not the same operational risk as the same finding on an internet-facing authentication service. The asset criticality, exposure, and data sensitivity must be incorporated in triage. In the AI era, a third factor must be added: whether the vulnerability class is amenable to AI-assisted exploitation. Memory corruption bugs in popular open-source software, browser JIT vulnerabilities, and TLS implementation flaws are exactly the vulnerability types where AI exploitation tools perform well.

Vulnerability management programs need metrics that reflect the AI-era threat environment. Three metrics deserve priority. Mean time to exploit (MTTE) is the elapsed time from disclosure to working exploit availability. In the AI era, this should be tracked per vulnerability class: AI-amenable exploit classes (memory corruption, JIT bugs, type confusion) carry a near-zero MTTE assumption for well-resourced adversaries. Your metrics should flag findings in these classes for expedited treatment regardless of CVSS score. Mean time to remediate (MTTR) should be tracked separately from MTTP because compensating controls are valid remediation in environments where patches cannot be immediately applied. MTTR that counts compensating control deployment as remediation gives a more accurate picture of organizational risk reduction velocity than MTTP alone. Exploit availability ratio is the percentage of your current open finding inventory for which working exploits are publicly available (in Metasploit, ExploitDB, or threat intelligence feeds). This metric tells you what fraction of your open findings represent immediate tactical risk versus theoretical risk. Organizations with high exploit availability ratios on open findings should examine whether their patch SLAs are calibrated appropriately. A fourth metric worth tracking in the Glasswing era is CVD notification coverage: the percentage of findings you received advance notice of through coordinated disclosure programs before public CVE publication. Glasswing partner organizations receive this notification for Glasswing-attributed findings.

The 30/60/90-day patching SLA structure was designed to match organizational patch testing and deployment capacity to the threat environment of the early 2010s. It has become a compliance checkbox in many organizations, with teams focused on meeting the SLA rather than on reducing actual risk. The problems with this structure in the AI era are specific. The 30-day SLA for critical findings assumes that the organization has 30 days before exploitation is likely. For AI-amenable exploit classes, this assumption is false from day one of public disclosure. The SLA structure treats all critical findings equally regardless of exploit availability, exposure, or asset criticality. A CVSS 9.5 finding in an air-gapped system with no known exploit and a CVSS 9.5 finding in an internet-facing service with confirmed active exploitation both fall into the same 30-day bucket, which is absurd from a risk management perspective. The SLA structure creates organizational incentives to avoid out-of-cycle patching because it disrupts change management processes. This means that even when security teams identify an urgent finding, the organizational process friction creates delays that do not reflect actual urgency. Organizations that want to adapt their patching programs to the AI era need to add an emergency patching tier above critical that applies when: a finding has a confirmed working exploit, the affected system is internet-facing or production-critical, and the vulnerability class is AI-amenable. This tier should have a 24-72 hour remediation target with defined escalation paths to bypass standard change management.

Risk-based patching replaces the single-variable CVSS sorting approach with a multi-factor prioritization model that produces a more accurate ranking of actual organizational risk. The core factors are: CVSS base score (severity of impact if exploited), exploit availability (confirmed working exploit in public tools or threat intelligence), exposure (internet-facing vs. internal vs. air-gapped), asset criticality (defined in a CMDB or asset inventory with business context), and active exploitation (CISA KEV membership, threat intelligence feeds). Each factor can be weighted and scored to produce a composite priority score for each finding. Commercial vulnerability management platforms including Tenable Lumin, Qualys TruRisk, and Rapid7's Risk Score incorporate some of these factors. The key operational requirement for risk-based patching is that asset criticality metadata is maintained in a current CMDB or equivalent. Organizations without accurate asset inventories cannot implement effective risk-based patching because they cannot answer the exposure and criticality questions. In the Glasswing context, a sixth factor should be added: Glasswing attribution. If a finding is Glasswing-attributed and the CVE has been published, adversaries with AI tools have had access to the vulnerability details since publication and may have developed exploits already. Glasswing-attributed CVEs in the AI-amenable exploit class should receive automatic emergency tier treatment regardless of other factors.

Adapting to AI-era vulnerability discovery requires changes at the organizational level, not just the tool level. The first organizational change is an emergency patching process with a clear trigger criteria and a streamlined approval workflow. Emergency patching should not require a standard change advisory board (CAB) approval cycle. It requires a defined approver (typically the CISO or a delegated security authority), a documented risk rationale, and a rapid deployment path that can be executed within 24-72 hours. The second organizational change is integrating threat intelligence into the patching workflow. Vulnerability scanners tell you what CVEs are present. Threat intelligence feeds tell you which of those CVEs have working exploits and are being actively targeted. The combination of scanner output with threat intelligence enrichment is the foundation of risk-based patching. The third organizational change is expanding who participates in vulnerability management decisions. AI-era vulnerability management requires input from asset owners (who can assess criticality and exposure), development teams (who can assess patch compatibility and testing requirements), and operations teams (who can execute deployment). Security teams cannot make good prioritization decisions without this input, and asset owners cannot make good risk decisions without security context. The fourth change is updating board and CISO reporting metrics from MTTP-only to a multi-metric dashboard that includes exploit availability ratio and MTTE for the AI-amenable finding classes.

The nine confirmed Glasswing CVEs illustrate the MTTE problem concretely. The wolfSSL certificate forgery (CVE-2026-5194, CVSS 9.1) affects a TLS implementation library embedded in a large number of IoT devices, embedded systems, and server applications. wolfSSL is used in millions of deployments. Certificate forgery at CVSS 9.1 enables man-in-the-middle attacks against TLS-protected communications. This is exactly the type of vulnerability where AI exploitation tooling excels: TLS protocol implementation bugs require precise technical reasoning but are well-defined enough that AI tools can develop proof-of-concept exploits systematically. The FreeBSD NFS RCE (CVE-2026-4747) affects network-attached storage and FreeBSD-based systems. Remote code execution through NFS is a high-value vulnerability class for initial access. The V8 adversarial code execution findings from ExploitBench demonstrate that Mythos can solve browser JIT exploitation challenges that no other AI model can approach. Browser vulnerabilities in V8 affect Chrome, Edge, and every Electron application. The common thread across these CVEs is that they are in widely deployed software, they are in exploit-amenable vulnerability classes, and AI tools can develop working exploits in the same session as discovery. Organizations that identify these CVEs in their environments through Glasswing notifications or public disclosure should treat them as emergency-tier findings.

The Mythos Brief includes a working MTTE calculator and risk-based patch prioritization framework developed from the Glasswing program's findings. The following components are available to Mythos Brief subscribers.