AI Bug-Hunting Drove ~1,500 High-Severity CVEs in June 2026: Prioritizing the Patch Window
AI models are now finding software flaws at scale. Epoch AI counted roughly 1,500 high-severity and critical CVEs reported in June 2026, about 3.5x the previous monthly record, while real exploitation still arrives within hours of disclosure. This walks through why patch prioritization by exploitability, plus identity-bound inline policy at the AI request boundary, is the control that holds between disclosure and patch.

On July 3, 2026, The Decoder reported that Epoch AI had charted roughly 1,500 high-severity and critical CVEs disclosed in June 2026 by 21 organizations, about 3.5 times the previous monthly record. The jump tracks the arrival of AI models that hunt for bugs at scale: Anthropic's Project Glasswing surfaced more than 10,000 high and critical findings across around 150 partners, and OpenAI's Daybreak program ran a parallel effort after the April release of Claude Mythos Preview. AI vulnerability discovery is now a standing input to the disclosure pipeline, and the volume is not coming back down.
I want to walk through what that surge does to a platform team's patch queue, and the control that holds in the window between a disclosure and the patch that closes it.
AI vulnerability discovery at model speed
The mechanism behind the June numbers is straightforward. Large models trained on code, fuzzers, and exploit corpora can read a repository, reason about a vulnerable path, and file a reproducible report faster than a human researcher reviewing the same code. When a lab points that capability at its partner ecosystem, the output is measured in thousands of findings per program rather than dozens.
For the AI stack specifically, this matters more than for most of the software estate. Inference servers, agent frameworks, model gateways, and vector stores are young code with wide network exposure and thin security review histories. They are exactly the surface these programs mine first. The June LiteLLM CVE wave, which put an authentication bypass in a widely deployed model proxy into circulation, is the pattern the reader should expect to repeat across the inference tier through the rest of 2026.
The disclosure-to-patch window
FIRST, the body that runs the CVE forecasting work, now projects roughly 66,000 CVEs for 2026. A platform team cannot patch 66,000 anything. The number that governs risk is not the disclosure count. It is the time between a disclosure landing in a feed and the fix reaching production.
That window is where exposure lives, because exploitation now moves at machine speed. Google Mandiant's M-Trends 2026 report, built on more than 500,000 hours of frontline incident response, found that the median time between initial access and handoff to a secondary threat group collapsed to 22 seconds in 2025, down from over 8 hours in 2022. When a proxy or inference server ships an advisory on a Friday, an automated campaign can be exercising it before the on-call engineer has finished reading the changelog. CISA moved the LiteLLM remote-code-execution CVE into its Known Exploited Vulnerabilities catalog within weeks of disclosure for exactly this reason.
Prioritize by exploitability, not by CVE count
The volume is unworkable as a flat queue and workable as a ranked one. Two public signals do the ranking. CISA's KEV catalog marks the CVEs that are being exploited in the wild right now, which makes KEV membership a hard "patch this cycle" flag. FIRST's Exploit Prediction Scoring System (EPSS) assigns every CVE a probability of exploitation in the next 30 days, and the distribution is steep: the large majority of CVEs never cross a meaningful exploitability threshold, so a small ranked subset carries most of the real-world risk.
A triage pass that pulls both signals turns the June flood into a short list. The following filters a batch of CVE IDs down to the ones that are either KEV-listed or above an EPSS cut, using the public CISA and FIRST feeds.
The output is the queue you actually work this week. Everything else waits for the normal maintenance cycle. This is patch discipline, not a security control, and it leaves the disclosure-to-patch window open by design.
A compensating control for the AI request path
Prioritization decides patch order. It does nothing for the hours or days a ranked-but-unpatched vulnerability sits in production. For the subset of those vulnerabilities that an attacker reaches over HTTP AI traffic, an authorization bypass in a model proxy, an injection-class flaw in prompt or response handling, an unauthenticated route that fronts an LLM, the compensating control is an identity-aware policy layer at the AI request boundary.
The property that matters is what an unpatched, reachable flaw can touch once it is triggered. A stateless enforcement proxy binds every AI call to a verified identity, evaluates a per-route and per-role policy before the request reaches the model, fails closed on error or ambiguity, and holds no long-lived provider keys for an attacker to harvest. A bypass that lands behind that layer still has to satisfy the policy to move traffic. A generic policy for a high-sensitivity route reads like this.
This does not patch the CVE, scan for it, or help with a flaw that runs as local process execution, arrives over STDIO, or abuses a static key stolen out of band. It narrows what an AI-traffic-reachable vulnerability can do inside the window, and it does so inline, before the request lands. The identity-aware gateway architecture is the design pattern that produces those properties.
The forensic record when the window is open
There is a second reason to run enforcement inline during a high-disclosure period. If an AI-traffic-reachable flaw is exploited before the patch lands, the per-decision audit record is the evidence of what happened. A signed record for every AI request, carrying the identity, the role, the policy version in force, and the decision outcome, reconstructs which calls a compromised route actually served. EU AI Act Article 12, effective for high-risk systems on August 2, 2026, requires that traceability as a standing obligation. An unpatched-window incident is when a deployer discovers whether the records exist. Building them before the incident is the difference between a scoped disclosure and an open-ended one.
DeepInspect
This is exactly what DeepInspect does. DeepInspect sits inline between your users and agents and the LLM APIs they call, as a model-agnostic stateless proxy. For every request it evaluates identity, data classification, model authorization, and organizational policy, and makes a pass, redact, or block decision before the traffic reaches the model. It stores no long-lived provider keys, and it commits a signed per-decision audit record before the response returns to the application.
Against a disclosure feed running toward 66,000 CVEs for the year, that layer is the control that does not depend on your patch queue being current. It cannot fix a vulnerable dependency, and it makes no claim to. It reduces what an AI-traffic-reachable flaw can reach while the fix is in flight, and it produces the record that scopes the incident if the flaw is exercised first.
If you are running AI inference in a regulated environment and your exposure is currently bounded only by how fast your team can patch, book a technical deep dive at deepinspect.ai.
Frequently asked questions
- Does AI vulnerability discovery actually change my risk, or just the CVE count?
It changes both, in different directions. The raw disclosure count rises, which is a workload problem for the team triaging feeds. The underlying risk to a specific deployment depends on whether the newly found flaws are reachable and exploitable in your configuration, which is what KEV and EPSS help you rank. The AI stack is disproportionately affected because inference servers, model proxies, and agent frameworks are young, network-exposed code that these programs mine early. The practical effect is a heavier, faster-moving queue against the same inference infrastructure, which is why prioritization and a compensating control both matter more than they did a year ago.
- How do KEV and EPSS differ, and should I use both?
Use both. CISA's Known Exploited Vulnerabilities catalog is a binary signal of confirmed in-the-wild exploitation, so KEV membership means patch now regardless of any score. FIRST's Exploit Prediction Scoring System is a probability, updated daily, that a given CVE will be exploited in the next 30 days. KEV tells you what is being used against people today. EPSS tells you where to spend attention on everything not yet in KEV. Ranking your open CVEs by KEV membership first and EPSS score second collapses a several-thousand-item feed into a working list of a few dozen for the current cycle.
- Can an AI gateway replace patching?
No, and treating it as a replacement is the wrong reading. Patching removes the vulnerability. An identity-aware gateway is a compensating control that limits what a still-unpatched, AI-traffic-reachable flaw can do in the window before the fix ships. The two operate on different timelines: the patch closes the hole permanently, the gateway constrains exposure continuously. For vulnerabilities that do not touch the HTTP AI request path, such as local process execution or a stolen static key used out of band, the gateway offers no help and the patch is the only control.
- Which June 2026 vulnerabilities sit inside a gateway's boundary?
The ones an attacker reaches through the AI request or response path. Authentication and authorization bypasses in model proxies, injection-class flaws in prompt or response handling, and unauthenticated routes that front an LLM are inside the boundary, because a policy layer that binds identity and fails closed changes what those flaws can reach. The LiteLLM authentication bypass from the June wave is a representative example. Flaws in local tooling, build pipelines, or transport layers the gateway never sees are outside it, and belong entirely to the patch queue.
- How does inline enforcement help forensics if we are exploited before patching?
The per-decision audit record is the reconstruction. Because the proxy commits a signed record for every AI request before the response returns, carrying identity, role, policy version, and outcome, an incident responder can determine which calls a compromised route actually served and under what authorization. That record supports the EU AI Act Article 12 traceability obligation and gives legal and compliance teams a bounded account of the exposure. Without it, a deployer investigating an unpatched-window exploitation is reconstructing events from application logs the same failing component controlled.