Patching AI-Discovered Vulnerabilities: The Real Rule
Discovery method is not a severity input. Validation provenance is the field that changes your patch queue.
AI-discovered vulnerabilities do not earn a faster patch than anything else in your queue.
The first half of 2026 published 35,364 CVEs and 85 of them reached the CISA catalog of confirmed exploitation. That is 0.24 percent. The feed grew, and the set that earns a ticket barely moved.
Table of Contents
- The 2026 CVE Feed Changed Shape
- Why Discovery Method Is Not a Severity Input
- Validation Provenance Is the Field You Are Missing
- AI-Discovered Vulnerabilities Sit at Both Ends of One Spectrum
- What an Unreproduced Report Actually Costs
- Adding Provenance to Your Intake
The 2026 CVE Feed Changed Shape
The first half of 2026 published 35,364 CVEs, and September alone accounted for 14,943 of them, roughly 245 percent above January. The mid-year 2026 CVE counts from Jerry Gamblin set that same half year against the CISA record of confirmed exploitation and came back with 85 entries, or 0.24 percent of everything published. The feed changed size dramatically and the exploited subset did not move with it.
Volume went vertical and confirmed exploitation stayed flat, which is the fact that should govern everything downstream of intake. Picture a typical Tuesday morning: forty fresh CVEs landed overnight, and three of them name an AI agent in the discovery credit. Those three feel like they deserve a different lane, and the rest of this piece is about whether they actually do.
Why Discovery Method Is Not a Severity Input
The intuitive worry runs like this: if an agent found the bug by reading source code, an attacker with the same tooling can rediscover it cheaply, so the clock must be shorter. Rediscovery cost does fall, but it falls for the entire class of bugs at once rather than for the specific ticket sitting in your queue. It changes the weather over the whole industry, not the forecast for one host that you own.
What actually moves a single CVE up a queue has not changed: evidence that somebody is exploiting it, reachability inside your own estate, and whether a fix exists to deploy. The EPSS exploit prediction model exists precisely because fewer than 5 percent of published CVEs are ever exploited in the wild. The CISA Known Exploited Vulnerabilities catalog sits at the confirmed end of that same spectrum.
Validation Provenance Is the Field You Are Missing
Validation provenance is a single field, recorded when a finding arrives, that answers one question: who reproduced this, and what did they attach as proof. It is not a score, it does not replace EPSS or KEV, and it costs nothing to collect because the advisory usually states it outright. Its job is to separate two reports that look identical on a dashboard and then behave nothing alike in practice.
Most teams already read this information and then throw it away. The guide to thinning the CVE flood from the SANS Internet Storm Center is a fair example of the standard approach, which treats every CVE as provenance-neutral once it has a number. Four values cover nearly everything that arrives:
- Agent-reproduced and human-reviewed, with a patch already merged upstream.
- Reproduced by the reporter, with a crashing input or proof of concept attached.
- Described only, with no reproduction steps and no artifact anyone can run.
- Generated prose that references functions the codebase does not contain.
AI-Discovered Vulnerabilities Sit at Both Ends of One Spectrum
The Big Sleep agent from Google reported 20 real vulnerabilities, each one reproduced by the agent before a human expert reviewed it and sent it on. The Big Sleep research write-up is explicit that reproduction comes before disclosure, which is why those findings arrived carrying patches instead of questions. On a provenance field that is the top value, higher than most human reports in the same inbox.
Get Patch Priority’s stories in your inbox
Join Medium for free to get updates from this writer.
The opposite end of the same spectrum arrives as confident, well-formatted prose with nothing underneath it. Both reports can honestly carry the words found by AI, and an intake form that records only the discovery method will file them in exactly the same place. One of them is ordinary patch-now work and the other is an unpaid research assignment with no deadline.
What an Unreproduced Report Actually Costs
The curl project now states in its vulnerability disclosure policy that there is no bug bounty, and it asks reporters not to paste AI-generated explanations into their submissions. Triage cost closed that program, not a shortage of genuine bugs in the codebase. A maintainer reading a fabricated stack trace spends exactly the same evening as one reading a real finding, and only learns which it was at the end of it.
An enterprise intake queue runs on the same economics and has no bounty program to cancel when it gets expensive. Every report that cannot be reproduced consumes an engineer who was scheduled to ship a fix for something that can, and that trade stays invisible unless somebody writes it down. Recording provenance at the door is how the cost becomes a number you can argue with.
Adding Provenance to Your Intake
None of this needs a procurement cycle. Nucleus carries a validation field on vulnerability intake and other platforms are adding one, but a mandatory column on whatever record you already keep does the same work in week one. What matters is that the field cannot be left blank and that triage is required to read it before assigning a lane.
Back to that typical Tuesday and its three AI-credited CVEs. Two of them arrive agent-reproduced with upstream patches available, so they join the normal patch-now lane on their technical merits alone. The third carries a description and no reproduction, which means it waits behind every finding that has one.
- Add a provenance field to the intake record with a fixed set of values and no free text.
- Populate it from the advisory itself: reproduction, human review, and upstream fix status.
- Let reproduction plus an available fix promote a CVE, and let a missing reproduction hold it back.
- Review the unreproduced bucket on a weekly cadence so a genuine finding never rots there.
AI-discovered Vulnerabilities FAQs
Are AI-discovered vulnerabilities more likely to be exploited?
Not as a rule, because exploitation tracks attacker economics rather than who filed the report. A flaw in an internet-facing product with a public exploit outranks an agent-found parser bug in a library nothing reaches, and it does so for reasons that have nothing to do with discovery. Treat the discovery credit as metadata, not as a severity input.
How do I tell a real agent finding from an AI-generated report?
Look for the reproduction rather than the quality of the prose. A genuine agent finding ships with a crashing input, a patch reference, or a named human reviewer who confirmed it before disclosure. A generated report describes behaviour in general terms, cites code paths you cannot locate, and gets vaguer the more precisely you question it.
Does the 2026 CVE spike mean my patch queue has to grow?
Not proportionally, and assuming otherwise is how teams end up sizing capacity against a feed instead of against risk. The published count grew by thousands of entries across 2026 while the set with confirmed exploitation moved by dozens. Size the queue from your own capacity and from exploitation evidence, exactly as you did before the spike.
Should discovery credit ever change the severity score of a CVE?
No, because severity describes impact and exploitability, and neither of those depends on who first noticed the bug. Discovery credit belongs in the audit trail, where it stays useful for later questions about the report. Provenance belongs in the queue logic, which is a separate field answering a separate question about whether the finding is real.
Where does provenance fit next to EPSS and KEV?
Underneath both of them, as a gate rather than as a score. EPSS estimates how likely exploitation is and KEV confirms that it has already happened, but both of them assume the finding they are scoring exists. Provenance answers that prior question, so read it first and apply the other two afterwards.
