GTIWizCloud SecurityVulnerability ManagementAI SecurityGoogle Cloud

AI Era Vulnerability Trends: Separating Real Exploitable Risk from CVE Noise with Google Threat Intelligence and Wiz

Jorge Liauw Calo
Jorge Liauw CaloSecurity Engineer @ Google Cloud
•10 min read
AI Era Vulnerability Trends: Separating Real Exploitable Risk from CVE Noise with Google Threat Intelligence and Wiz

Due to AI, more vulnerabilities are being discovered and exploited faster than ever before. When over 10,000 CVEs drop in a single month, treating every “Critical” or “High” CVE the same will burn out your engineering teams. Here is what the latest Google Threat Intelligence research tells us, and how we combine Google Threat Intelligence with Wiz to separate a paper vulnerability from a truly exploitable risk.


10,740 CVEs in a Single Month: The Reality Behind the Headlines

If it feels like your vulnerability management backlog has been exploding lately, you are not imagining things. The Google Threat Intelligence Group (GTIG) just published a deep-dive study, Vulnerability Discovery and Exploitation Trends in the AI Era, analyzing every vulnerability disclosed and exploited between January 2025 and August 2026.

The headline number jumps right off the chart: monthly CVE disclosures doubled in 2026, climbing from 5,045 in January 2026 to 10,477 in July, and reaching 10,740 in August 2026.

Count of vulnerabilities disclosed per month from January 2025 to August 2026
Figure 1: Count of vulnerabilities disclosed per month, January 2025 to August 2026 (Source: Google Threat Intelligence Group)

When you show a chart like this to a CISO or a SecOps team, the immediate reaction is usually panic: “How are we supposed to patch 10,740 vulnerabilities a month?”

The short answer is: you don’t, and you shouldn’t try to.

When we look closer at the data, the most important takeaway is not just the sheer volume of CVEs being detected. The real finding is that not all vulnerabilities have the same criticality.


Separating a “Vulnerability” from a Real Vulnerability

In security engineering, this is where you separate the men from the boys: separating a theoretical CVE on a spreadsheet from a vulnerability that can actually be exploited to compromise your environment.

For years, security teams have relied on static CVSS severity scores to drive patching SLAs. If a scanner flags a CVE above 7.0 or 8.0, it goes straight into the urgent queue. In 2026, that approach is broken for two reasons highlighted in the GTIG research:

  1. CVE Inflation Is Real: Automated CVE assignment policies across open-source projects inflate raw numbers massively. Between January and August 2026, vulnerabilities mentioning the Linux Kernel alone accounted for roughly 5,000 CVEs, yet GTIG observed zero exploited in-the-wild zero-days among them.
  2. Only 3% Are High/Critical Risk, and Only 0.23% Are Exploited: Instead of static CVSS scores, GTIG rates flaws using intelligence-driven GTIG Vulnerability Risk Ratings based on real-world exploitation consequences and threat actor activity. Even though High-Risk disclosures grew by 167% in 2026 (from 131 in January to 350 in August), they still make up only 3% of all disclosed vulnerabilities.

Look at what happens when we break down that exact same 10,740 monthly CVE chart by GTIG Risk Rating:

Count of vulnerabilities disclosed by GTIG vulnerability risk rating from January 2025 to August 2026
Figure 2: Monthly vulnerabilities broken down by GTIG Risk Rating. Even at peak volume in August 2026, only 350 out of 10,740 CVEs were rated High or Critical Risk (Source: GTIG)

Even more striking: across the entire 2026 dataset, only 0.23% of all disclosed vulnerabilities (roughly 1 in 431) were ever observed being exploited in the wild.

If you treat every CVE equally or rely purely on static severity scores without looking at exploitability, 99.7% of your emergency patching effort goes toward chasing noise while the 1-in-431 flaw that attackers are actively weaponizing sits buried in a Jira backlog.


Why Speed Matters: N-Days Are Weaponized in Days, Not Months

If only a small fraction of CVEs are exploited in the wild, why is AI still making the threat landscape so much more dangerous?

Because when a consequential vulnerability is disclosed, AI compresses the time between disclosure and active exploitation to just a few days.

Between January and August 2026, GTIG recorded 141 distinct vulnerabilities exploited in the wild, already surpassing the total for the entire year of 2025 (127). Monthly exploited vulnerabilities nearly doubled from an average of 10.5 per month in 2025 to 18 per month in 2026.

Count of all vulnerabilities exploited by N-Days and Zero-Days from January 2025 to August 2026
Figure 3: Count of vulnerabilities exploited in the wild by N-Days (green) and Zero-Days (red), January 2025 to August 2026 (Source: GTIG)

Look at the split between Zero-Days (red) and N-Days (green) in Figure 3:

  • Zero-Day exploitation grew modestly for most of the year (averaging 8 per month in 2025 vs. 11 per month in 2026, with a jump to 22 in August 2026).
  • High-Risk N-Day exploitation more than doubled, jumping from 28 in 2025 to 75 between January and August 2026.

Why are N-Days surging so fast? Discovering a brand-new zero-day from scratch is still hard. Instead, threat actors are using LLMs to automatically diff patches between software versions, read vendor advisories the minute they drop, and generate working Proof-of-Concept (PoC) exploit scripts in hours.

A Real-World Example: CVE-2026-1731 (Exploited in 4 Days)

The GTIG report shares a textbook example: CVE-2026-1731, an unauthenticated OS command injection flaw in BeyondTrust Privileged Remote Access and Remote Support.

  • Discovered by an AI Agent: It was found autonomously by a third-party AI research agent (Hacktron AI).
  • Exploited Within 4 Days: Within just four days of public disclosure, GTIG observed threat actors exploiting CVE-2026-1731 in the wild to breach enterprise perimeters.
  • Six Threat Clusters in 7 Days: Within seven days, five more threat groups piled on for privilege escalation, data exfiltration, and dropping secondary payloads like SNOWLIGHT and SPARKRAT.

If your patching process relies on a monthly scan and a 30-day SLA, a 4-day weaponization window means the attacker is already inside before your ticket is even triaged.


Where Google Threat Intelligence and Wiz Come Together

So how do we solve this? With 10,740 CVEs a month on one side and attackers weaponizing the consequential ones within 4 days on the other, we need two things working together: real-time threat intelligence and full-stack cloud attack surface context.

1. Google Threat Intelligence: Going Beyond Severity to Exploitability

Instead of guessing from a static CVSS score, Google Threat Intelligence (GTI) (combining Mandiant frontline incident response, VirusTotal, and Google telemetry) tells you the real-world exploitability of a vulnerability:

  • Is there a Proof-of-Concept (PoC) exploit circulating in the wild?
  • Are threat actors actively exploiting this CVE in campaigns right now?
  • Does it allow unauthenticated Remote Code Execution (RCE) on an exposed service?

2. Wiz: Visualizing the Full Attack Surface and Toxic Combinations

Even when Google Threat Intelligence tells you a vulnerability is actively exploited, you still need to know: “Where does this sit in my cloud environment, and is it actually reachable?”

A critical CVE on an isolated dev container with no internet ingress, no IAM permissions, and no access to production data is not your top emergency. A vulnerability that sits inside a Toxic Combination, however, is an immediate breach waiting to happen.

With Wiz, we don’t look at vulnerabilities in a vacuum. We visualize and prioritize them across the full attack surface by looking for Toxic Combinations:

  • Publicly Exposed: Is the vulnerable workload, container, or API endpoint reachable from the internet?
  • Exploitable Vulnerability: Does it carry a CVE that Google Threat Intelligence flags as actively exploited or high-risk?
  • High IAM Privileges: Does the workload run with an over-privileged service account or IAM role that allows privilege escalation?
  • Misconfigurations: Are there network misconfigurations, exposed cleartext secrets, or overly permissive firewall rules in the path?
  • Sensitive Data Access: If compromised, does this workload have a lateral movement path to production databases or storage buckets holding sensitive data?

Every factor in that chain multiplies the real-world risk of exploitation. Combining Google Threat Intelligence (knowing which vulnerabilities attackers actually use) with Wiz (knowing where those vulnerabilities form a toxic combination in your cloud) is how you cut through 10,000 monthly CVEs and fix what truly matters first.


Two More Important Takeaways from the GTIG Blog

Beyond the headline CVE numbers, there are two more findings in the GTIG research that every security engineer and CISO should take away:

1. “AI as the Hunter”: 50% of AI-Discovered Bugs Lead to RCE

When human researchers and traditional scanners report CVEs, 69% are Low Risk and only 26% result in Remote Code Execution (RCE).

When autonomous AI agents discover vulnerabilities, that profile flips:

  • 58% of AI-discovered CVEs are Medium Risk (more than double the non-AI rate, while Low Risk drops to 39%).
  • Exactly 50% of all AI-discovered vulnerabilities result in Remote Code Execution (RCE), nearly double the 26% baseline.

Autonomous AI agents are not just flagging surface-level syntax warnings. They trace complex, multi-step code paths across C/C++ libraries and runtimes, finding memory corruption and logic bypasses that traditional static analyzers miss.

2. “AI as the Hunted”: Your AI Stack Is the New Attack Surface

As organizations rapidly deploy generative AI in the cloud, attackers are targeting the AI operational stack itself. GTIG tracked 2,076 CVEs in AI systems (with over 1,500 disclosed in 2026 alone):

  • AI Orchestration & Agent Frameworks (50% of all AI flaws): Tools like Langflow, Flowise, LangChain, Dify, LlamaIndex, and MCP servers accounted for 782 CVEs in 2026 (a 347% surge), often leading to RCE via untrusted workflow serialization or tool calling.
  • Inference Gateways (The New Perimeter): Serving tools like LiteLLM, vLLM, Ollama, and NVIDIA Triton had 212 CVEs in 2026, with 24% stemming from unauthenticated APIs or SSRF.
  • Active In-the-Wild Exploitation: Threat actors are already exploiting AI middleware flaws like CVE-2026-42271 (LiteLLM MCP command injection) and CVE-2026-5027 / CVE-2025-3248 (Langflow arbitrary file write and unauthenticated RCE).

If an engineering team deploys an exposed LiteLLM or Langflow gateway in your cloud with an over-privileged service account and access to internal vector databases, you suddenly have a textbook Toxic Combination on your AI perimeter.


Key Takeaways to Bring Back to Your Team

  1. Look at Exploitability, Not Just CVSS Severity: With 10,740 CVEs a month and only 0.23% exploited in the wild, static CVSS scores create alert fatigue. Use Google Threat Intelligence to separate real threats from CVE noise.
  2. Prioritize Toxic Combinations with Wiz: Combine GTI exploitability context with Wiz to see the full attack surface. Prioritize vulnerabilities that chain together public exposure, high IAM privileges, misconfigurations, and sensitive data access. Breaking any link in that chain immediately reduces your risk.
  3. Secure Your Edge and AI Middleware: Over 65% of exploited edge gateway flaws in 2026 were High/Critical risk, and AI orchestration tools (Langflow, LiteLLM, MCP) are the new target. Use Wiz to discover shadow AI services in your cloud and lock down their exposure and IAM permissions.
  4. Match AI Speed with Agentic Defense: When N-days are weaponized in 4 days, manual triage is too slow. Pair proactive AI code review (like Google AI Threat Defense and CodeMender) with automated cloud posture and runtime visibility.

Read the full Google Threat Intelligence Group research report here: Vulnerability Discovery and Exploitation Trends in the AI Era.

Jorge Liauw Calo
Written By

Jorge Liauw Calo

Security Engineer at Google Cloud (Google Cybershield) with 13+ years of experience in Cybersecurity across highly regulated industries including Semiconductor, Banking, Fintech, and Insurance. Active member of the Google Cloud Community BeNeLux and Google Cloud Security Community Amsterdam.