The AI CVE exploitation evidence story: Headlines are scarier than reality

TL;DR

• Vulnerability intelligence is currently monitoring over 1,250 CVEs related to 50 unique vendor product types
• We’ve been monitoring exploit evidence associated with AI CVEs, and we’ve provided our assessment of 10 AI products
• Our research has identified that actual AI exploitation risk is only at 4.2% 

Note: Any CVE information provided is accurate as of the publication date of this blog. New CVEs may surface after publication. 

With all the AI hype in the news lately around fully agentic ransomware and AI tech acting on its own whims, the vulnerability sector of our threat intel team set out to answer a question: What is the actual impact of AI on real vulnerabilities, based on data we can see right now? 

After completing an analysis of all the AI-related CVEs we’re tracking within our SOC—including 1,250+ CVEs spanning 50 AI vendors—we determined that actual AI exploitation evidence is only at 4.2% by tracking observed exploit risk factors, combined with actual in-the-wild attacker activity. 

The impact of AI on real vulnerabilities, as told by our SOC data

However, CVE creation and volume continues to grow exponentially. We’ve been monitoring new AI CVEs daily, because the vulnerabilities published for specific AI tools are constantly evolving as we learn about new exploitations. 

Even more concerning is how scanning technology vendors have struggled to keep up with publishing unique AI CVE identifiers to enable their customers to manage preventing AI exploitation effectively. Although scanning technology cannot be the sole vulnerability identified risk tracker, practitioners have an opportunity to leverage existing tools as a way of identifying and remediating AI-specific CVE vulnerabilities. 

TL;DR, traditional exploitation risk factors are still relevant, and we’ll continue to narrow down the influx of AI CVE creation down to the actual vulnerabilities worth fixing. Exploit evidence sources we’re tracking include the actual exploit threat intel, vendor advisories, PoCs demonstrating exploitation tactics, EPSS score fluctuations, and even a few CISA KEV additions. 

After diving into the data, the exploitation story is clear; only a small percentage of AI CVEs have actually been exploited. Out of the 50 AI tool vendors we’re monitoring, we’re giving you a tactical deep dive on the top ten AI tools and their riskiest vulnerabilities. This analysis captures a narrow scope of CVE exploitation assessment that includes the top weaponized vulnerabilities, the identified active exploitation factors, and the combined scanning technology coverage we’ve identified to date. 

Overall, CVEs with clear and measurable exploit evidence (i.e. news of exploitation, CISA, EPSS scores, and AI vendor-specific PoC exploits) are very minimal, even for the ten AI products we evaluated. The percentage of confirmed exploited AI CVEs with these observed exploitation activity factors is minimal (4.2%). 

In addition to tracking AI product-specific CVEs, we also reviewed vulnerability scanning technologies and how they tackle the massive challenge of keeping up with published CVEs. The vulnerability scanner scope is specific to Tenable, Qualys, and Rapid7. Each vendor has maintained their own unique approach to their vulnerability scanner CVE coverage. 

Tenable and Rapid7 publicly post their AI specific vulnerabilities, and Tenable Nessus uses an artificial intelligence plug-in family to detail specific CVEs. We only focused on this Nessus family, even though web application scanning, cloud, and container modules also cover AI CVEs. 

Rapid7 maintains a public website link for each CVE for every product type, including AI. Qualys publishes CVE coverage on a daily basis, although they rarely provide public QIDs. Qualys primarily maintains a console access required QID assignment for each CVE. 

To evaluate the scanner coverage, we calculated CVE coverage by verifying if the latest three scanners did or did not have a scanner identifier published. We focused on verifying if AI product CVEs with exploit factors were covered, and then evaluated if the scanners had specific identifiers published to track each AI CVE. 

The ten AI tools we’ve focused on for CVEs with in-the-wild exploitation are: 

In the AI tool summaries below, we’ve identified: 

1. The AI tool and summary, with the total AI CVEs being tracked
2. Vulnerability exploitation status: 
   1. Top CVEs to prioritize
   2. AI tool advisory (vendor exploitation confession)/PoC status
   3. EPSS score percentage (the probability of exploit risk occurring in the next 30 days)
   4. Exploit status factors including CISA KEV and exploit links (i.e. code or news demonstrating exploitation, or public or ransomware exploit tags
   5. The mitigation necessary to address the vulnerability
3. Active CVE exploitation exposure weighed all this evidence and determined the top CVEs identified with each AI tool product (shown in the tables below)
4. Scanning technology percentage coverage: We’ve evaluated if the three vulnerability major scanning technologies have an established unique identifier, to ensure their customers are able to identify if the AI CVE is in their infrastructure. 

Our first summary is for Claude.

Claude tool vulnerability exploitation profile

Claude is an Anthropic family of large language models (LLMs) including the Claude API, developer platform, and agentic tools including Claude Code (CLI/IDE coding agent), Claude Cowork, Claude Design, Claude in Chrome, Claude in Excel, and Claude in PowerPoint. The CVE-relevant exposure is entirely in the agentic tooling layer. Claude Code is used for executing shell commands, reading local files, and connecting to MCP servers.

Currently, we’re tracking 50 CVEs associated with Claude. Here are the top three: 

The scanning technology is only covering 44% of the above CVEs for Claude, and prompt injection is the most severe exploitation category for Claude.

A successful Claude prompt injection could lead to unauthorized data exfiltration, system compromise, or malicious threat actors using tool execution. Claude Code continues to mitigate prompt injection with layered controls beyond the model itself, including mandatory approval for sensitive operations, context-aware analysis of harmful instructions, and a sandboxed bash tool isolating filesystem and network access. Claude enterprise users should also enforce a managed policy file that locks deny-rules (destructive commands, credential paths, MCP trust levels) at the system level.

Flowise AI vulnerability exploitation profile

Flowise AI is an open source, low-/no-code visual tool for building LLM applications and AI agent workflows by dragging and connecting nodes (LLMs, vector stores, tools, memory, etc.) instead of writing code.

We’re currently tracking 96 CVEs associated with Flowise. Here are the top three: 

Flowise scanning coverage was low at 33%, which is a meaningful gap, given the exploit possibility.

Flowise uses Custom MCP nodes to spin up local servers via npx command line, configured from user-supplied JSON, and that convenience is exactly where all three vulnerabilities converge. 

Authentication has been historically (CVE-2025-59528) weak by default, so the application is reachable by anyone on the network unless authentication is explicitly enabled. Because mcpServerConfig is trusted enough to reach Function() (CVE-2025-59528) or a shell (CVE-2025-8943) unvalidated, the fix has to happen at that exact handoff point—sanitize and allowlist the input before it’s allowed to trigger code execution. 

A single missed check can fully reverse a patch’s protection, so sandboxing the MCP path is the last line of defense against one bypass becoming a full compromise.

Gradio AI tool vulnerability exploitation profile

Gradio is an open-source Python library for quickly building web UIs around machine learning models and LLM apps.

Currently, Expel vulnerability intel is tracking 54 CVEs associated with Gradio. Here are the top three: 

Scanning technology is currently covering 44% of these Gradio CVEs.

We recommend ensuring you’ve identified the use of Gradio across your infrastructure. The most effective practice is to address the high AI CVE exploitation probability by ensuring you have visibility of the Gradio versions in your environment, and update identified older instances with current versions. Lastly, beyond vulnerability management, Gradio’s use of port 7860 has raised security concerns because it created a highly predictable entry point for automated scanners, botnets, and malicious actors. Gradio users should consider implementing firewall rules to block unnecessary traffic.   

Hugging Face AI tool vulnerability exploitation profile 

Hugging Face is an open source platform (often called “the GitHub of machine learning”) that hosts models, datasets, and demo apps for the AI/ML community.

We’re tracking 39 CVEs associated with Hugging Face. Here are the top three: 

The common thread across all three Hugging Face exploited risk CVEs is insufficient trust boundaries, including deserialization, sandboxing, and network exposure. Since the CVEs we covered had only 22% scanning coverage, we recommend hardening the three boundaries (safe formats, real isolation, auth, and segmentation) to reduce the possibility of exploitation. 

The safe-formats boundary can be hardened by replacing pickle and torch.load with non-executable formats like safetensors for any model or config from an untrusted source. The isolation boundary is hardened by sandboxing untrusted code execution at the OS level  (containers, gVisor, Firecracker), rather than trusting library-level allow-lists. The auth-and-segmentation boundary is hardened by requiring authentication and TLS on every inference endpoint and keeping it off the public internet via network segmentation. By hardening these trust boundaries, the Hugging Face CVE exploitation patterns are significantly reduced.

LangChain AI tool vulnerability exploitation profile

LangChain is an open source framework for building applications powered by LLMs, providing modular tools to chain together prompts, models, memory, external data sources, and agents so developers can more easily create complex LLM-driven workflows like chatbots, RAG systems, and autonomous agents.

We’re currently tracking 55 LangChain CVEs. Here are the top three: 

Scanning technology covers 44% of the top three exploited Langchain vulnerabilities.

LangChain vulnerabilities security exploitation is specific to serialization injection, remote code execution (RCE), and path traversal. These CVEs allow threat actors to use prompt injection or malicious configurations to steal secrets, read private files, or run arbitrary code on host servers.

LangFlow AI tool vulnerability exploitation profile

Langflow is an open source, low-code visual framework (with drag-and-drop building blocks) for designing, testing, and deploying AI workflows and agents built on LLMs. 

Our vulnerability team is tracking 121 CVEs associated with LangFlow. Here are the top six we’re tracking: 

Currently, 100% of scanning technology covers the top six AI vulnerabilities for Langflow. Each of these CVEs boil down to the same failure—an endpoint built to execute code or run a workflow on a user’s behalf, without verifying who is asking or what they’re actually allowed to run. Three of these CVEs are pure authentication gaps (CVE-2025-3248, CVE-2026-0770, CVE-2026-33017), one is a browser-session trust failure (CVE-2025-34291), and one is an authorization gap post-login (CVE-2026-55255). 

All six let an attacker’s input—not the platform’s own logic—decide what code executes, and whose credentials to leverage. Close this gap by putting a real identity check in front of every code-executing endpoint at each stage that can fail. Disabling auto-login and requiring credentials closes the authentication gaps behind CVE-2025-3248, CVE-2026-0770, and CVE-2026-33017. 

For CVE-2025-34291, this occurred because Langflow trusted requests from any website (not just its own) so if a logged-in user simply visited a malicious page in another browser tab, that page could quietly act on their behalf and hijack their session, no password required. The fix is to only trust requests coming from known, approved websites, and add a second layer of protection so a hidden request can’t slip through, even if it looks legitimate. 

Lastly, for CVE-2026-55255, Langflow correctly checks that a user was logged in, but fails to check whether that specific user actually owned the workflow they were trying to run, meaning any logged-in user could run someone else’s workflow just by knowing their unique identifier. To reduce the probability of exploitation, check ownership every time, not just login status. Put both CVE fixes in place, and the system only runs what a verified, authorized person actually asked for, not whatever an attacker manages to sneak through.

LiteLLM AI tool vulnerability exploitation profile

LiteLLM is an open source AI gateway and Python SDK that provides a single, unified, OpenAI-compatible API to call over 100 LLMl providers—including Anthropic, Google Gemini, AWS Bedrock, and Azure—allowing developers to swap models or fallback providers without rewriting application code. 

Currently we’re tracking 8 (40 available) CVEs associated with LiteLLM. Here are the top three: 

In our review, 89% of scanning technologies covered the top three indicated vulnerabilities of LiteLLM. In CVE-2026-42208, input was allowed to influence the structure or control flow of a privileged operation, rather than being treated as pure data. For these CVEs, ensure AI trust boundaries are reviewed: sandboxes, auth checks, and the supply chain. 

Reduce the sandbox escape probability by enforcing OS-level isolation via containers, gVisor, or open source Firecracker, rather than relying on library-level allow-lists as the only barrier around untrusted code execution. 

Reduce injection likelihood by parameterizing every database query, and validating all headers and inputs before they reach authentication logic so an attacker’s crafted token or header can never bypass the check. Finally, address the supply chain by pinning exact package versions and hashes, verifying signatures, and using official vetted images instead of relying on public registries.

Ollama AI tool vulnerability exploitation profile

Ollama is another open source tool that lets you download and run LLMs locally on your own computer, with a simple command-line interface and API for managing models like Llama, Mistral, and others.

We’re tracking 30 CVEs for Ollama. Here are the top three:

All vulnerability scanners cover these three CVEs at 100%. All Ollama CVEs with a higher change of exploitation have a similar lesson to learn, as a user must refrain from relying on a self-hosted AI tool that leverages convenience-first defaults. These stem from: no auth by default, permissive path handling, and trusting redirect headers. If users don’t adjust the defaults, the AI tool becomes dangerous the moment it’s exposed to any untrusted network or an untrusted model source. The patch matters. However, users should consider network isolation, input validation on paths and models, and treating model registries as untrusted third parties. These actions will actually close the exploitation gap and improve security.

OpenClaw AI tool vulnerability exploitation profile

OpenClaw is a self-hosted open-source ‘personal AI assistant’ (formerly called Clawdbot/Moltbot) connecting LLMs like Claude, GPT, and Gemini to messaging platforms (WhatsApp, Telegram, Slack, Discord). The root of exploitation is in its ability to execute commands, access files, and take autonomous actions. These OpenClaw vulnerabilities are older, so there’s really not at much exploitation activity as earlier this year. We’re covering OpenClaw now because AI tools will continue to evolve, so a lower threat level now doesn’t mean the same for the future.  

Currently, we’re tracking 96 OpenClaw CVEs (additional CVEs are published). Here are the top three: 

Scanning technology is currently only covering 44% of the higher exploit evidence for the CVEs above.

This AI tool has a higher exploitation likelihood based on news resources that demonstrate CVE exploits leveraging malware use, data disclosure, and API key compromise. OpenClaw’s default port is 18789, so we suggest establishing necessary controls to address how the tool is using this port. We also recommend verifying how many assets are using OpenClaw across your infrastructure. Although patching reduces an individual vulnerability, authentication, permission minimization, sandbox hardening, and credential rotation are what limit damage the next time a similar flaw surfaces for this AI tool. 

N8n AI tools vulnerability exploitation profile

N8n is an open source, self-hosted workflow automation platform that lets you visually build multi-step processes and AI agents—connecting LLMs (OpenAI, Anthropic, etc.), tools, and hundreds of app integrations—using a drag-and-drop node editor with optional custom code. 

Our team is currently tracking 161 CVEs for N8n. Here are the top three: 

The n8n workflow automation platform has a high volume of severe security vulnerabilities focused on: sandbox escapes, remote code execution (RCE), and unauthenticated file reading. For these three highly exploited CVEs, 66% of the CVEs we identified are covered by scanner technology. 

When we consider sandbox escape risk, content-type parsers alone aren’t the trust boundaries you can rely on. Patch promptly, segment the networks, enforce the least-privilege workflow access, and vault credentials together to reduce the blast radius across your AI infrastructure. Network segmentation can be hardened by isolating n8n in its own network zone, so a full-instance compromise can’t pivot laterally into production systems. Restrict workflow creation and edits to only trusted users— most n8n RCEs require nothing more than basic edit rights to exploit. Be sure to store secrets in a dedicated vault rather than directly in n8n, so a compromised instance doesn’t allow credential compromise to every connected service. 

What we’ve learned about CVEs for AI tools

Conclusions we’ve come to for AI tool specific CVEs are based on our own data analysis.

Despite the ongoing large volume of AI CVEs published, those responsible for remediation continue to  struggle to keep up with AI vulnerabilities. As each day we are inundated by the AI CVEs being identified and published. For the CVEs with high exploitation indicators CVEs (33 covered), the louder the AI exploitation news and attention, the more likely that the scanning technology will scramble to establish an AI CVE scanning technology identifier. This is also demonstrated with the CISA KEV CVEs. To date, only eleven CISA AI CVEs have been added to the KEV exploit database (see table below). For these AI CISA CVEs, 94% of scanner technology has stepped up and addressed them so their customers can identify and address the exploitation probability.  

Consequently, scanning technologies currently struggle to comprehensively cover AI CVE identification, as the overall scanning technology coverage presents a range of coverage. Scanning technology coverage is clearly not enough. To address exploitation likelihood, we have to identify if AI tool vulnerabilities are present in our own infrastructure. We cannot address and prioritize remediation if we don’t have a strong vulnerability identification coverage. 

Once we do know what vulnerabilities exist, we’re able to track mitigation and prioritize accordingly. This prioritization continues to ensure AI CVE remediation makes progress toward a massive undertaking, to address the AI tool industry weaknesses.

After all this CVE research, it’s clear that AI tool users should still rely on the CVE system to track AI-related vulnerabilities. CVE identification, paired with available scanning technology, still remains an established and reasonable method for identifying and remediating AI vulnerabilities attackers are leveraging. While AI tools and their weaknesses will continue to be sensationalized with exploit headlines, at least we’re able to leverage vulnerability scanning tools as a solid step toward addressing the AI vulnerabilities with actual indicators of exploitation.