Notifications
Clear all
Topic starter
28/08/2026 12:04 pm
TL;DR: Only 4.2% of 1,250 plus AI-related CVEs across 50 vendor product types showed evidence of real-world exploitation, even as scanning coverage and CVE volume continue to lag the pace of new disclosures, according to Expel’s SOC analysis. The practical issue is not AI hype, but whether security teams can identify the small set of AI vulnerabilities that actually change risk.
NHIMG editorial — based on content published by Expel: AI CVE exploitation risk and scanner coverage analysis
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.
Questions worth separating out
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.
Q: Why do AI systems create identity risk as well as model risk?
A: Because AI systems rarely act alone.
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.
Practitioner guidance
- 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.
- 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.
- 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.
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
👉 Read Expel's analysis of AI CVE exploitation, scanner coverage, and remediation priority →
AI CVE exploitation risk is low, but coverage gaps remain?
Explore further
28/08/2026 12:04 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: AI CVE exploitation is still rare despite rapid vulnerability growth
