Google Threat Intelligence Group (GTIG) published the report “Vulnerability Discovery and Exploitation Trends in the AI Era” on how AI affects vulnerability discovery and exploitation. Over the observation window from January 1, 2025, to August 31, 2026, the volume of disclosures doubled: from 5,045 CVEs per month in January 2026 to a peak of 10,740 in August 2026, and in the first eight months of 2026, 141 vulnerabilities were exploited in the wild — more than in all of 2025 (127). The authors note that AI is changing not so much the volume of findings as their profile: vulnerabilities discovered with AI are more often dangerous — 58% of them receive a medium GTIG rating versus 28% for regular findings, and RCE, i.e., remote code execution, accounts for 50% of their exploitation outcomes versus 26% on average.

image

What happened

The report was prepared by Robin Grunewald, Supriya Mazumdar, and Kelli Vanderlee; it covers the period from January 1, 2025, to August 31, 2026. Within the reporting window, zero-days accounted for 62% of all vulnerabilities exploited in the wild, peaking in August 2026: 22 zero-days versus a baseline of 8–12 per month. The main exploitation platform remains perimeter devices: the edge/security appliance class, which includes routers and gateways, accounts for 14% of exploited vulnerabilities, with more than 65% of exploited vulnerabilities in this class having a high or critical rating. The report lists specific spikes: 75 high-risk vulnerabilities from vendor TOTOLINK and 128 high-risk vulnerabilities from Oracle and Linux drivers in August 2026.

Context

Methodologically, more important than any numbers is that GTIG is for the first time systematically separating vulnerabilities discovered with AI from regular findings: attribution is built on lab registries of frontier programs and tags in CISA and MITRE advisories. The authors formulate the mechanism of influence as a hypothesis: attackers are most likely using LLMs not so much to find fundamentally new vulnerabilities as to automate the analysis of patches, vulnerability announcements, and PoC code, in order to quickly turn known n-day vulnerabilities — already disclosed, with a patch released but not installed everywhere — into working exploits. The volume of disclosures should be assessed cautiously in this context: gross growth is a poor metric of danger, because part of the flow is an artifact of automatic identifier distribution, and according to the report, about 5,000 CVEs were generated from a single “Linux Kernel” description.

Why this matters for the industry

For the industry, the report records a shift in value from counting CVEs to rapid prioritization of what is actually being exploited: the buyer is already asking vendors which of the ten thousand monthly CVEs is important for their infrastructure, and classic scanning lists answer this question worse and worse. The pressure falls primarily on perimeter device vendors, whose products are most often among those exploited, and on security teams whose patching SLAs are calculated for slower cycles of turning an advisory into an exploit. Against this backdrop, a window opens for “patch priority” products: agents that monitor CISA and MITRE advisories and PoC feeds, match them with the customer’s inventory, and form a prioritized patch queue; such MVPs are being assembled right now without new infrastructure, and the August 2026 cycle provides ready-made test benchmarks for them. As expected, scanner and vulnerability management platform vendors will start embedding “found with AI” signals and weaponization speed into prioritization logic, and the key metric for SOC tools will be the completeness of coverage of vulnerabilities actually exploited in the wild.

Why this matters for users

The practical takeaway for the reader is the opposite of the headline fear in the style of “CVEs have doubled”: according to GTIG, only 0.23% of disclosed CVEs are actually exploited, roughly one in 431. The perimeter should be checked: if there are routers, gateways, or corporate services with public management interfaces on the network, they remain the main target, and high-risk n-days for them now need to be closed faster than before. Specific steps: conduct an inventory of perimeter devices, review the patching order for high and critical n-days, guided by the current spikes from the report, and treat vulnerabilities marked as found with AI as more prioritized. For those who run their own CVE feed intake, it is also useful to check the pipeline for duplicates: some identifiers are generated automatically, and the flow can be artificially inflated.

What is still unknown / limitations

The main limitation is the status of causality: the hypothesis that LLMs accelerate the transformation of known n-days into working exploits has not been verified by measurements, because the report has no baseline of time from advisory to exploit before and after the emergence of LLMs, and there is no direct link in the data between the surge in disclosures and LLMs. The “found with AI” attribution relies on visible markers, i.e., frontier program registries and tags in CISA and MITRE advisories, so it systematically underestimates completeness and skews the sample toward large vendors that run such programs; because of this, part of the rating spread may be explained by the vendor profile rather than AI itself. For shares like 58% medium rating or 50% RCE, the data lacks the size of the AI-discovered vulnerabilities subsample, and with a small number of observations, such percentages are extremely unstable. As expected, as vendor participation in frontier programs expands, the subsample will become statistically robust and the cited figures can be rechecked.

Sources

Author

Look at AI, editorial team