AI is finding vulnerabilities. Can we fix them fast enough?

Rumblings of My Mind | Enterprise Signal

More discoveries could mean shorter vulnerability lifetimes. Getting there requires the same ambition for remediation that AI is bringing to discovery.

Finding a vulnerability is progress. It reveals a weakness that can now be understood and repaired.

But discovery also creates work. Someone must reproduce the finding, assess its consequences, develop a safe fix and get that fix into affected systems. As AI helps researchers uncover weaknesses in widely used software, the capacity to complete that journey deserves closer attention.

My hypothesis is that AI-assisted discovery is increasing pressure on remediation. If we apply AI and operational improvements across the fixing process with comparable ambition, that pressure could become a transition to a better balance: more vulnerabilities found, more resolved, and less time for them to remain hidden or unfixed.

Recent cases offer evidence for the pressure and for possible responses. The longer-term outcome remains something to establish.

When useful research becomes an operational strain

In May 2026, curl founder Daniel Stenberg described a team receiving increasingly detailed, high-quality security reports. Verification, assessment, patching, historical investigation and advisory writing were consuming his days and straining the maintainers. This was useful research arriving as a sustained operational workload. Curl: The pressure

In October, curl announced that LOW and MEDIUM reports would move to public GitHub issues from 26 October, with HIGH and CRITICAL reports remaining private. The intention was to share the burden more widely. Stenberg acknowledged an exposure trade-off from public handling. At the time of writing, the change is announced and has yet to take effect. Curl's policy announcement

The distinction matters. Handling more good findings requires capacity to act on them. Filtering inaccurate submissions can save time, but it cannot eliminate the repair work created by genuine vulnerabilities.

External researchers are helping make that work visible. They should be part of the solution. The question is whether the organisations receiving their findings have the people, tools and processes to respond sustainably.

Faster fixes can still leave more work waiting

HackerOne's 2026 report captures the tension. Across severities, average resolution time fell from 135 to 62 days, while open valid reports increased 131% between 2024 and 2026. In a separate survey, approximately 70% of security leaders said validated findings were entering their backlog faster than teams could remediate them. Report and methodology

These are platform observations and survey responses, rather than a causal estimate of AI's contribution. Programme growth, changing scope, staffing and the difficulty of findings could also influence the results. The commercial interest of a platform selling remediation services warrants scrutiny too.

The operational lesson is still useful: an average calculated from resolved cases leaves the waiting cases outside the calculation. Faster closure can coexist with a larger queue.

Leaders therefore need to see the age and composition of unresolved work alongside the speed of completed fixes. An improving average is welcome. It does not, by itself, show that the organisation is keeping up.

PHP: discovery clarified the impact; repair required difficult choices

PHP provides a concrete account of what happens after a serious finding becomes actionable.

Calif dates its initial findings to 1 August 2026, its first report to PHP to 11 August, and the sharing of a working proof of concept to 14 August. Its researcher describes using models alongside detailed knowledge of PHP's vulnerability history. Calif's research and timeline

The PHP Foundation says the report established the impact of a root cause that had concerned maintainers earlier. Fixing it involved compatibility and design trade-offs, scarce specialist expertise and coordination with distributors. Supported patched releases arrived on 21 October, after the planned release was brought forward by a day following disclosure disruption. PHP Foundation account

That is 71 calendar days from the first Calif report to release. It is neither a measure of engineering hours nor proof of a missed deadline. It also excludes the time enterprises subsequently needed to deploy the update.

The case illustrates an important limit to discovery speed. Showing that a defect has serious consequences can change its priority. Choosing a safe repair for a widely used software runtime remains consequential engineering work.

OpenSSL offers another documented sequence. Its January advisory records AISLE researcher Stanislav Fort's report of the HIGH-severity CVE-2025-15467 on 14 December 2025, with fixed versions identified on 27 January 2026: 44 calendar days. The fix is credited to Igor Ustinov. OpenSSL advisory

AISLE attributes the wider release's 12 discoveries to its AI system, with human validation. That attribution comes from the research vendor; the maintainer advisory corroborates the vulnerability, reporting date and repair credit. AISLE announcement

The two intervals are not a performance ranking. Different defects, dependencies and constraints create different repair work. Neither establishes when all affected systems became protected.

Explore the cases: Choose a case, replay its timeline and inspect the original sources. The explorer also includes Firefox, curl and the separately labelled DARPA repair demonstration.

Firefox shows what a response can achieve

The evidence also includes a constructive outcome.

In March 2026, Mozilla described how reproducible reports from Anthropic helped engineers validate findings and begin landing fixes within hours. That collaboration produced fixes for 22 security-sensitive bugs in Firefox 148. Mozilla's March account

In April, Mozilla reported that Firefox 150 included fixes for 271 vulnerabilities identified during its initial Mythos Preview evaluation. It also described substantial engineering reprioritisation to meet the challenge. Mozilla's April account

These are different evaluations, so their counts should not become a model productivity multiplier. They do show a team converting a substantial body of findings into a released response.

For enterprise leaders, the combination deserves attention: actionable evidence, capable engineers and a willingness to redirect work. A released fix still needs adoption, and an intense response is not automatically a sustainable operating model. But this case gives us a reason to investigate how that capacity can be built.

Taken together, the cases demonstrate consequential AI-assisted research and real operational responses. They do not quantify a representative increase in valid findings per hour among independent analysts. That would require comparable targets, effort and researcher populations. The direction is supported by cases; the general productivity effect remains incompletely measured.

Bring the same ambition to fixing

AI-assisted remediation should cover the journey from a credible finding to verified protection.

That includes reproduction and deduplication, impact assessment, patch creation, testing, backporting, release, deployment and verification. A tool can improve one stage while the overall process continues waiting somewhere else.

Automated repair has credible demonstrations. DARPA's 2025 AI Cyber Challenge reported 54 synthetic vulnerabilities discovered and 43 patched. Separately, systems found 18 non-synthetic vulnerabilities and supplied 11 patches. These results show capability in a bounded competition; they do not establish enterprise deployment outcomes. DARPA results

Practical fit also matters. In the DeepVulGuard study, 17 Microsoft developers used a detection and repair tool on projects they owned. Among 24 fix suggestions receiving direct feedback in the combined-model analysis, only 25% were considered useful without significant problems. Earlier models limit what this says about current systems, but the integration lesson remains relevant. Study

Consider a hypothetical process in which patch creation takes an hour and release coordination takes three weeks. Reducing the hour helps. The three weeks still need an owner.

The enterprise response should therefore combine AI investment with engineering capacity and clearer decisions. Better reproduction evidence can reduce validation effort. Better tests can reduce review uncertainty. Clear ownership can shorten deployment delays. Specialist maintainers still need time and funding to make the difficult calls.

The useful test is whether total effort, rework and elapsed time improve through to verified protection.

A higher pace could become sustainable

Here is the future I think we should test for.

Faster discovery may initially reveal an accumulated stock of old defects. The known workload rises because weaknesses become visible. If effective remediation capacity expands sufficiently, organisations could work through that stock while sustaining the higher rate of new findings.

Matching incoming work stabilises a backlog. Clearing it requires effective completions to exceed arrivals for a period. Counts need context: ten complex findings are different work from ten minor ones, and one repair can resolve several reports.

This balance would also keep moving. New defects, expanding software estates, more difficult findings and rework can increase the capacity required. A smaller queue could even reflect reduced reporting rather than better software. Sustained progress needs evidence of effective repair and continued testing coverage.

The cases do not demonstrate that this equilibrium has arrived. They make it a credible operational hypothesis worth measuring.

“Normal” could mean running at a higher pace with a manageable workload, rather than recreating an earlier staffing model or release cadence. More frequent discoveries would then be compatible with vulnerabilities remaining hidden or unresolved for less time.

Measure the lifetime, including the work still waiting

To establish that benefit, we need three separate intervals:

AI-assisted discovery could improve the first. Engineering and operational improvements could shorten the others. A gain in one can be offset by deterioration elsewhere.

Introduction and deployment dates are often missing. CVE publication dates cannot substitute for them. This makes shorter vulnerability lifetime a measurable ambition whose general achievement has yet to be demonstrated.

For leadership, that changes what a useful security review should show: actionable arrivals against effective completions; the age of consequential unresolved work; waiting time at each stage; rework introduced by proposed fixes; and evidence that affected systems received protection. Administrative closure and accepted risk should remain distinguishable from completed repair.

A rising discovery count can be encouraging. Faster average fixes can be encouraging too. The question is whether those improvements are converting into a sustainable reduction in unresolved exposure.

The opportunity is more vulnerabilities discovered and less time left to live with them. Remediation needs the capacity to make that possible.

Evidence and scope: Primary sources rechecked on 24 October 2026. The selected operational events fall within the preceding two years, in 2025–2026; they are a purposive selection, not a representative sample. The explorer is dated 23 October 2026. HackerOne's platform window is July 2025–June 2026 with earlier comparisons; its 111-leader survey spans six countries and is separate from platform data. A matched programme panel was not established. Researcher AI-attribution claims, maintainer observations, interpretation and future hypotheses are distinguished. No Qatar/GCC effect estimate is inferred.

Independent personal research based on publicly available sources. The analysis and interpretations reflect my own understanding and may evolve as new evidence emerges.