AI CVE exploitation is still rare despite rapid vulnerability growth

At a glance

What this is: Expel’s analysis finds that confirmed exploitation remains limited across AI-related CVEs, with most of the risk concentrated in a small number of vulnerabilities and uneven scanner coverage.

Why it matters: Security teams need a way to separate AI CVEs that are genuinely exploitable from the much larger set of disclosed issues, because remediation capacity and scanning visibility are both lagging the disclosure pace.

By the numbers:

• Only 4.2% of the AI-related CVEs Expel tracked showed actual exploitation evidence.

Context

AI vulnerability management now sits at the intersection of disclosure volume, exploit evidence, and scanner coverage. A growing CVE list does not automatically mean a growing attack problem, but it does make prioritisation harder when tools, workflows, and teams cannot keep pace with publication.

For identity and access programmes, the relevance is practical. AI tools often expose APIs, agentic execution paths, local file access, and connected credentials, so the question is not whether every AI CVE matters, but which ones create real pathways into data, systems, or privileged workflows.

This makes the article a useful signal for NHI and agentic AI governance as well as broader vulnerability management. The pattern is typical of fast-moving technology categories: disclosure outpaces dependable coverage, and security teams need stronger triage rules rather than broader alarm.

Key questions

Q: What should teams do first when AI CVEs are flooding the queue?

A: Start by separating disclosed AI CVEs into three groups: confirmed exploitation, credible exploit signals, and unproven theoretical issues. That gives remediation a defensible order of operations and prevents the largest noise bucket from consuming the backlog. Teams should then validate whether their scanners can actually identify the AI products they run.

Q: Why do some AI CVEs create more operational risk than others?

A: AI CVEs become higher risk when they expose code execution, file access, authentication gaps, or delegated tool access. Those flaws can turn an AI application into a path toward secrets, internal systems, or privileged workflows. The vulnerability is therefore not just in the software bug, but in the access it unlocks.

Q: How do security teams know if AI is improving vulnerability management?

A: AI is working when it improves decision quality, not just throughput. Look for faster identification of exposed assets, better prioritisation of exploitable findings, and fewer critical paths remaining after remediation. If the output is just a bigger queue processed faster, the programme has not changed.

Q: What happens when an exploited AI tool can reach connected credentials?

A: The incident stops being a single application flaw and becomes an access-control problem. Once an attacker can use API keys, tokens, or connected services through the AI component, they can move from one vulnerable endpoint into data access, workflow abuse, or broader compromise. That is why identity scope matters in AI triage.

Threat narrative

Attacker objective: The attacker wants to turn a vulnerable AI tool into a foothold for code execution, data access, or control over connected services.

1. Entry occurs through exposed AI tooling, vulnerable endpoints, or agentic interfaces that accept untrusted input or connected commands.
2. Credential or execution abuse follows when the attacker reaches code execution, file access, or delegated tool access through the vulnerable AI component.
3. Escalation happens as the compromise pivots into secrets, internal files, connected services, or broader workflow control.
4. Impact is theft of data, compromise of connected systems, or execution of malicious actions through the AI tool chain.

Breaches seen in the wild

• LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI CVE volume is not the same as AI exploitation risk. Expel’s data shows that the market should stop equating disclosure growth with immediate attacker activity. That distinction matters because remediation teams have finite attention, and false urgency can be as damaging as neglect. The practical conclusion is that AI vulnerability governance should prioritise exploitability evidence, not headline count.

Coverage gaps are now part of the risk model. When scanners cannot consistently identify AI-specific CVEs, organisations lose the ability to measure exposure with confidence. That creates an operating blind spot, not just a tooling inconvenience. The practical conclusion is that AI vulnerability governance now depends on coverage validation as much as patch management.

Agentic AI makes vulnerability triage an identity question. The article’s Claude, Flowise, LangChain, Langflow, and n8n examples show that code execution, tool access, and delegated credentials are often the meaningful blast-radius multipliers. When AI systems can act through tokens, local files, MCP servers, or connected services, the real control question becomes who or what is allowed to act. The practical conclusion is that AI security teams should treat permissions and execution scope as part of vulnerability response.

Exploitability-based prioritisation is becoming the new baseline for AI governance. The useful concept here is AI exploitation coverage gap: the space between published AI CVEs and the subset that scanners and teams can actually see, classify, and action. That gap is where overlooked risk accumulates. The practical conclusion is that organisations need a repeatable method for separating theoretical AI flaws from the vulnerabilities that change operational risk.

What this signals

AI exploitation coverage gap: The practical problem is not just how many AI CVEs exist, but how many of them your tooling can actually recognise and route. When scanners lag the product landscape, prioritisation becomes a governance decision instead of a measurement exercise. Teams should assume that unlabelled exposure is still exposure, even if it never lands in the standard queue.

The article also reinforces a broader NHI lesson: once AI tools execute commands, access files, or reach external services, vulnerability response and identity governance converge. At that point, tokens, MCP trust paths, and connected services are not side issues. They are the mechanism by which a software flaw becomes a real operational compromise.

For practitioners

• Prioritise AI CVEs by exploit evidence Rank disclosures using exploit activity, vendor advisories, proof-of-concept availability, EPSS movement, and KEV inclusion before assigning remediation priority.
• Validate scanner coverage for AI products Check whether your vulnerability tools publish identifiable coverage for the specific AI platforms, gateways, and agentic tools you operate, not just generic AI support.
• Treat connected credentials as part of AI risk Review tokens, API keys, MCP trust relationships, and delegated access attached to AI tooling so an exploited CVE cannot become an access-control event.
• Segment code-executing AI workloads Isolate AI systems that can run commands, read local files, or connect to external services so exploitation cannot pivot into adjacent production systems.

Key takeaways

• AI CVE disclosure growth is outpacing the number of issues that appear to matter operationally, so exploit evidence is the best first filter.
• Scanner coverage is now part of the risk picture because an unclassified AI vulnerability can remain invisible to normal remediation workflows.
• When AI tools can execute code or use delegated credentials, vulnerability management and identity governance have to be handled together.

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.
• Scanner Coverage: The extent to which vulnerability scanners can recognise a specific CVE or exposed configuration in an environment. Coverage is useful only when it arrives soon enough to inform decisions, and it does not replace inventory or exploit intelligence when the race is already lost.
• Exploitability signal: Any indicator that a vulnerability is likely to be used soon or is already being used, such as exploitability ratings, proof-of-concept code, or catalog membership. These signals help convert a long vulnerability list into a shorter response queue.
• AI Exposure Management: AI Exposure Management is the practice of collecting, correlating, and prioritising AI-related risk signals across an enterprise. It goes beyond discovery by linking usage findings to identities, data sensitivity, and remediation ownership so teams can act on the exposures that matter most.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, machine identity security, and secrets management. It helps security practitioners connect access control decisions to the broader governance issues raised by AI tooling.