AI CVE exploitation is still rare despite rapid vulnerability growth

At a glance

What this is: This is an Expel analysis of AI-related CVEs showing that observed exploitation remains limited despite fast-growing vulnerability volume and uneven scanner coverage.

Why it matters: It matters because IAM, PAM, and security teams need to separate theoretical AI risk from exploitable exposure, especially where agentic tooling, credentials, and tool execution are involved.

By the numbers:

• Expel’s SOC analysis covered more than 1,250 AI-related CVEs across 50 vendor product types.
• Actual AI exploitation evidence was found in only 4.2% of the AI CVEs reviewed.
• Langflow’s scanner coverage reached 100% for its top six exploited CVEs, showing that coverage can improve when exploitation becomes visible.

👉 Read Expel's analysis of AI CVE exploitation, scanner coverage, and remediation priority

Context

AI CVE management is becoming harder because vulnerability volume is rising faster than many teams can triage, while scanner coverage remains uneven across products and modules. The central governance gap is not whether AI tools have flaws, but whether security teams can distinguish routine disclosure noise from vulnerabilities with evidence of active exploitation.

For identity teams, the risk concentrates where AI tooling can execute code, reach local files, or connect to external tools and MCP servers. That makes the control problem less about the model itself and more about the identities, permissions, and trust boundaries attached to the surrounding platform.

The article’s starting position is typical for modern AI tooling: broad exposure, mixed scanner maturity, and a small subset of vulnerabilities that carry real attack value.

Key questions

Q: What happens when AI CVEs are tracked without exploitation evidence?

A: Teams often waste remediation effort on vulnerabilities that look alarming but never cross the threshold into practical attack paths. The better approach is to combine CVE data with exploit signals such as PoCs, KEV entries, EPSS movement, and real attacker activity so that the queue reflects exposure, not noise.

Q: Why do AI systems create identity risk as well as model risk?

A: Because AI systems rarely act alone. They depend on service accounts, API tokens, cloud permissions, and data access paths, which means a model can behave safely while its identity layer is over-privileged. Treating AI risk as only a model problem misses the access surface where misuse and lateral movement usually begin.

Q: How should security teams use AI in vulnerability remediation workflows?

A: Use AI to reduce triage noise, identify the likely owner, and assemble fix-ready work that can move directly into execution. If AI only ranks findings, remediation speed usually stays constrained by human coordination. The practical test is whether the tool shortens the path from detection to closure, not just from detection to prioritisation.

Q: How do organisations know whether their AI scanner coverage is good enough?

A: Coverage is only good enough if it detects the AI CVEs that matter most in your estate, especially those with public exploitation evidence. Compare scanner identifiers against a curated set of real exploited AI vulnerabilities, and treat missing identifiers as a governance gap that needs manual validation.

Technical breakdown

Why AI CVE volume is growing faster than practical remediation

AI tools are being shipped as frameworks, agents, workflow builders, and model-adjacent utilities, which creates a larger and more fragmented attack surface than a single model endpoint. Each tool may introduce its own web layer, local execution path, plugin model, file access routine, or integration point, and that multiplies the number of distinct CVEs. Security teams often inherit a mixed estate where some products publish public CVEs, some publish partial identifiers, and some leave defenders to correlate advisories, PoCs, EPSS, and KEV signals manually.

Practical implication: maintain a single AI CVE inventory that joins advisories, scanner output, and threat intel before prioritising remediation.

How exploitation evidence changes prioritisation

Exploitation evidence is the difference between a theoretical weakness and a vulnerability that should be treated as an active control failure. In this article’s model, evidence comes from observed attacker activity, vendor advisories, public proofs of concept, EPSS movement, and CISA KEV inclusion. That matters because raw CVE counts can overstate operational risk if they are not weighted by exposure and exploitability. For AI tooling, the highest-risk cases are often execution, injection, authentication bypass, and file access issues that sit directly on a trust boundary.

Practical implication: weight remediation queues by exploit evidence and trust-boundary impact, not by CVE count alone.

Why scanner coverage is not the same as risk coverage

Scanner coverage tells you whether a tool can name a vulnerability, not whether the organisation is actually protected from it. The article shows that some products had good coverage for the CVEs most clearly linked to exploitation, while others lagged badly. That creates a governance blind spot when teams assume a scanner’s absence of a finding equals absence of risk. In AI environments, coverage gaps are especially dangerous where local execution, custom nodes, or workflow builders can turn one missed identifier into a full compromise path.

Practical implication: test scanner visibility against known exploited AI CVEs and close the gaps where identifiers are missing.

Threat narrative

Attacker objective: The attacker wants to turn an AI tool’s trust boundary into code execution, secret access, or downstream compromise.

1. Entry occurs when an attacker targets an AI tool exposed through a public endpoint, weak authentication, or a vulnerable workflow component.
2. Escalation follows when the vulnerable AI tool permits code execution, file access, prompt injection, or misuse of trusted integrations such as MCP-connected tools.
3. Impact is achieved when the attacker steals secrets, runs arbitrary code, or pivots from the AI application into surrounding systems and data.

NHI Mgmt Group analysis

AI CVE inflation is a governance problem before it is a vulnerability problem. The article shows that thousands of disclosures can obscure the small set that actually matter to defenders. That creates prioritisation fatigue, where teams spend more time classifying noise than closing exploit paths. The lesson for practitioners is to treat AI CVE triage as a risk-ranking discipline, not a checklist exercise.

Agentic AI systems turn identity and execution into a single control plane. Where an AI tool can call MCP servers, read local files, or execute shell commands, the risk is no longer limited to the model. The surrounding identities, tokens, and approval boundaries become the real security perimeter. That is why NHI governance and privilege controls must extend into AI toolchains, not stop at model access.

Scanner coverage gaps create false confidence when AI platforms evolve faster than detection logic. Expel’s data shows that a scanner can lag badly even when exploitation is active, which leaves defenders blind to the handful of vulnerabilities that deserve urgent action. AI vulnerability visibility debt: when tooling cannot keep pace with AI-specific CVEs, remediation becomes a guessing game. Practitioners should measure identification coverage as a first-class risk metric.

Active exploitation, not disclosure volume, should drive remediation order. The most operationally relevant AI CVEs are those with public exploitation signals, KEV inclusion, or credible PoCs. That approach aligns with NIST CSF prioritisation logic and with identity programmes that already triage privilege and credential risk by blast radius. Practitioners should promote exploit evidence into the change-management queue before less material defects.

Identity governance will increasingly determine whether AI risk becomes enterprise risk. When AI tools are allowed to execute actions on behalf of users or services, the question becomes who or what is trusted to act. That is an IAM, PAM, and NHI question as much as an application security question. Practitioners should treat every code-executing AI workflow as a governed identity boundary.

What this signals

AI vulnerability management will become more about evidence quality than raw disclosure volume. Security teams should expect triage processes to converge on exploit signals, scanner confidence, and trust-boundary relevance. The operational question is whether your programme can distinguish a noisy AI CVE feed from the few issues that can actually alter blast radius.

AI toolchains that can call external services inherit identity governance requirements. If a workflow can execute commands, authenticate to downstream systems, or reach MCP-connected tools, then entitlement review and secret stewardship need to follow the workflow, not just the user. That is where NHI governance becomes a practical control, not a specialist side topic.

The right programme response is to build a repeatable bridge between vulnerability management, IAM, and runtime control. Security teams should anchor that work in the OWASP Agentic AI Top 10 and in internal policy that forces sensitive AI actions through explicit approval and audit.

For practitioners

• Build an exploited-CVE tiering model for AI tools Rank AI vulnerabilities by observed exploitation, EPSS, KEV status, and whether the flaw sits on a code-execution or data-access boundary. Use that tiering to decide which AI CVEs enter emergency remediation, not just routine patch queues.
• Inventory identity-bearing AI components List every AI workflow, agent, CLI tool, plugin, and custom node that can execute code, access files, or call external tools such as MCP servers. Map the service accounts, API keys, tokens, and approval steps attached to each one.
• Validate scanner coverage against known exploited AI CVEs Compare your scanner output with a curated set of public AI CVEs that have PoCs, vendor advisories, or KEV inclusion. Where identifiers are missing, treat that as a detection gap and compensate with manual review and compensating controls.
• Separate model risk from platform trust risk Do not assume that securing the model endpoint secures the workflow platform around it. Harden the surrounding identity layer with least privilege, approval gates for sensitive actions, and restricted trust relationships between AI tools and downstream systems.

Key takeaways

• The article shows that AI vulnerability volume is rising faster than most teams can interpret it, which makes exploit evidence the key triage signal.
• Only a small fraction of AI CVEs show real-world exploitation, but those flaws often sit on the exact paths that lead to secrets, code execution, or downstream compromise.
• Practitioners should treat AI scanners, identity controls, and exploit intelligence as one governance problem rather than three separate programmes.

Key terms

• AI CVE Exploitation Evidence: Evidence that a disclosed AI vulnerability is being used or is plausibly usable in real attacks. It includes public proof of concepts, exploit reporting, KEV inclusion, and threat intelligence indicating active attacker interest, not just the existence of a CVE record.
• Detection Coverage Gap: A detection coverage gap is a behavior, alert pattern, or attack path that existing rules do not reliably identify. In practice, it shows where telemetry exists but control logic is missing, too broad, or too slow to act on. Closing the gap usually requires rule tuning, new detections, or rule consolidation.
• Trust Boundary: A trust boundary is the point where one system’s authority should stop and another system’s authority should begin. For internal automation, weak trust boundaries let monitoring, remediation, and execution share privileges that should have remained separate.
• Agentic toolchain: A set of tools and services that AI agents can call to inspect, modify, or trigger actions across software workflows. These systems need identity and permission controls because they can act across boundaries without a human approving every step.

What's in the full report

Expel's full analysis covers the per-product vulnerability breakdown and scanner coverage detail this post intentionally leaves for the source:

• Per-tool CVE tables for Claude, Flowise, Gradio, Hugging Face, LangChain, Langflow, LiteLLM, n8n, Ollama, and OpenClaw
• The specific exploit evidence factors used to score each vulnerability, including PoCs, EPSS, KEV, and vendor advisory signals
• Scanner coverage comparison across Tenable, Qualys, and Rapid7 for the AI CVEs under review
• Mitigation guidance tied to individual AI products and versions, useful when you are already planning patch execution

👉 Expel's full post includes the product-by-product CVE tables, exploit indicators, and mitigation versions.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It is designed for practitioners who need to govern AI-connected systems, service accounts, and access boundaries with operational discipline.