2,130 AI-related CVEs were published in 2025 — a 34.6% year-over-year increase and more than a 200% rise since 2023, according to figures cited in industry reporting this month.
Growth in a vulnerability count is usually ambiguous. It can mean the software got worse, or that more people started looking, or that more software exists. Here it is mostly the third and second, and the composition of the number matters more than its size.
Most "AI vulnerabilities" are ordinary vulnerabilities
There is a persistent assumption that AI security means model behaviour — jailbreaks, alignment failures, adversarial examples. Those exist. They are not what the CVE count is made of.
Look at what actually gets numbers assigned:
- CVE-2026-9198 in Langflow — an unauthenticated endpoint chained to
exec(). CWE-94, code injection. This is a 2005-era bug class in a 2026 product. - Sandbox escapes in coding agents — process isolation failures.
- Predictable temp file paths leaking secrets — CWE-377, a bug class older than most of the engineers writing it.
- Prompt injection in pull request descriptions leading to code execution — untrusted input reaching a privileged execution path. Injection, structurally identical to SQL injection with a different interpreter.
- Localhost services bound to all interfaces — a configuration error, not an AI problem.
The pattern: AI tooling is being built fast by teams optimising for capability, and it is repeating the application security mistakes the industry spent twenty years learning to avoid. The novelty is the deployment context, not the vulnerability class.
That is genuinely good news for defenders, because it means existing AppSec discipline applies directly. Input validation, authentication on every endpoint, least privilege, no dynamic evaluation of untrusted strings, secure temp file creation. None of this requires new theory.
What is actually new
Three things do not reduce to classic AppSec.
Prompt injection has no complete fix. Every other injection class was solved by separating code from data — parameterised queries, output encoding, prepared statements. Large language models process instructions and data in the same channel by design. You can mitigate with input filtering, output constraints, and privilege separation, but you cannot parameterise a prompt. This is the one genuinely novel primitive, and it is why tool poisoning in MCP remains hard.
The blast radius per compromise is unusually high. AI tooling sits at credential aggregation points by function. An orchestration platform holds every API key its flows need; a coding assistant holds repository, cloud, and ticketing access. Compromise yields a configured, wired-up set of capabilities rather than a single secret.
The privilege requirement is inherent. An agent that cannot read your code cannot review it; an agent that cannot call your APIs cannot do the task. The utility and the risk come from the same property, so the usual advice to reduce privilege collides directly with the reason the tool exists.
Why the count will keep rising
Three drivers, none of which reverse soon:
Surface growth. More AI products exist every quarter, and each one is new code.
Researcher attention. Security research follows deployment. AI tooling is now widely enough deployed to be worth attacking, so it is now worth researching. Georgia Tech's Vibe Security Radar project tracked 35 CVEs in a single month attributable to AI coding tools.
AI-generated code entering production. A growing share of new code is written by assistants, at higher volume than human review can absorb. Whatever the per-line defect rate is, the total is rising because the denominator is.
That third driver is the one with the longest tail, and it will not show up as "AI CVEs." It shows up as ordinary CVEs in ordinary products that happen to have been written quickly.
Practical implications
Track AI tooling in your regular vulnerability management, not a separate AI programme. Langflow, agent frameworks, MCP servers, coding assistants, and vector databases are software with versions and CVEs. If they are not in the same inventory as everything else, they are not in the patch cycle.
Apply your existing AppSec review to AI features. Every AI feature has an ordinary attack surface underneath: an API, an authentication boundary, a data store, a set of credentials. Review that first. The model-specific concerns come after, not instead.
Treat prompt injection as an architecture problem. Since you cannot filter it away reliably, the mitigation is what the model can do after being successfully injected. Bound the tool surface, scope the credentials, require confirmation for irreversible actions. Design for injection succeeding.
Inventory the AI supply chain as a distinct artefact class. Model weights, datasets, fine-tunes, agent frameworks, and MCP servers all have provenance questions and none of them appear in a conventional dependency manifest.
How Safeguard helps
AI components in the same SBOM as everything else. Safeguard's Supply Chain Core inventories models, agent frameworks, MCP servers, IDE extensions, containers, and packages into one continuous CycloneDX and SPDX record — which is the precondition for AI tooling appearing in your patch cycle at all.
Prioritisation that reflects what AI hosts hold. A vulnerability on a component that aggregates model-provider keys, database credentials, and connector tokens deserves a different rank than the same score on an isolated service. Safeguard weights asset criticality, KEV membership, EPSS, and reachability together.
MCP and agent governance. Safeguard inventories which agent platforms and MCP servers run where, which credentials each holds, and gates tool exposure per-server with feature flags — so the post-injection blast radius is a bounded, documented set rather than whatever accumulated over time.
Lion for designing around successful injection. Lion runs alongside AI agents enforcing just-in-time secret brokering, capability scoping, egress allowlists, and signed audit trails. The premise is exactly the one this post argues for: assume the model can be induced to do the wrong thing, and constrain what the wrong thing can reach.
Griffin for the volume problem. As AI-generated code raises the defect count, remediation throughput becomes the bottleneck. Griffin authors and tests fixes across repositories in parallel.
Check whether your AI tooling appears in your vulnerability management inventory at all. For most organisations it does not, which means the 2,130 number describes a surface nobody is patching.
Sources: Help Net Security · Cloud Security Alliance — AI-Generated Code Vulnerability Surge · Cloud Security Alliance — AI Coding Assistants as Attack Surface · CrowdStrike 2026 Threat Hunting Report
