What are the most common LLM security vulnerabilities?

Two lists answer this and they are different. The risk list, from the OWASP Top 10 for LLM Applications, ranks prompt injection, insecure output handling, training-data poisoning, model denial of service, supply-chain compromise, sensitive information disclosure, system-prompt leakage, excessive agency, misinformation, and unbounded consumption. The CVE list, from what was actually filed in 2026, clusters into control-plane authentication bypass, multi-tenant isolation failure, pre-auth RCE in orchestration tooling, unsafe model-artifact deserialization, and configuration-to-command execution in MCP implementations. Program planning needs both.

Is prompt injection a CVE?

Prompt injection is a technique rather than a defect in a specific product, so it rarely carries a CVE identifier of its own. MITRE ATLAS catalogs it as AML.T0051 with direct and indirect sub-techniques. It appears inside CVEs as the enabling step: a vulnerability that lets injected instructions reach a tool call or an interpreter gets a number, and the injection is how the attacker gets there.

How fast are LLM infrastructure vulnerabilities exploited?

Faster than most patch windows. LiteLLM's CVE-2026-42208 saw exploitation roughly 26 hours after the advisory, and LMDeploy's CVE-2026-33626 in about 13 hours. Langflow's CVE-2026-55255 was reported as actively exploited on July 8, 2026, with CISA giving federal civilian agencies until July 10 to mitigate. A patch program alone leaves an exposure window measured in days against exploitation measured in hours, which is the argument for a compensating control at the traffic layer.

Does an AI gateway reduce LLM vulnerability risk?

It depends entirely on the gateway's own architecture, which the LiteLLM CVE wave demonstrated. A gateway that stores long-lived provider keys and evaluates its own authentication concentrates risk into one component. A stateless proxy that holds no persistent provider credentials, relies on identity verified upstream, and writes evidence to an independent store reduces both what a bypass reaches and what a compromise can erase. Ask what the gateway holds before asking what it blocks.

Which LLM vulnerabilities can a policy gateway actually stop?

It stops unauthorized model access, unauthorized data leaving in a prompt, and calls from identities or to endpoints that policy has not permitted, because all of those cross the HTTP AI boundary where the proxy sits. Remote code execution in an inference server, a poisoned weight file, and local STDIO command execution do not cross that boundary, and the honest description of the gateway's role there is detection of the attacker's subsequent model usage plus an independent forensic record. Patching and workload isolation remain the primary controls for those classes.

LLM Security Vulnerabilities: Five Classes of Real CVE in the 2026 AI Stack

The OWASP Top 10 for LLM Applications describes risks. It ranks prompt injection first, and it is right to. What it does not contain is a CVE number, a CVSS score, or a date on which a specific product in your stack became exploitable.

Those exist now, in volume. Epoch AI charted roughly 1,500 high-severity and critical CVEs reported in June 2026 by 21 organizations, about 3.5 times the previous monthly record, with FIRST projecting around 66,000 CVEs for the year (The Decoder). A meaningful share landed in the AI tooling stack itself. Read across them and the same five defects keep reappearing.

Class 1: authentication bypass in the AI control plane

Over the weekend of June 21 and 22, 2026, BerriAI disclosed five more LiteLLM vulnerabilities, led by CVE-2026-12773, a CVSS 7.3 authentication bypass in the UserAPIKeyAuth function that lets a caller reach proxied AI services without valid credentials (Threat-Modeling.com). That landed on top of CVE-2026-42271, an RCE that CISA added to its Known Exploited Vulnerabilities catalog on June 8. Seven LiteLLM CVEs in a single month.

The pattern generalizes past one project. An AI gateway is the component every model call in the environment passes through, holding provider keys and routing policy. Its authentication layer is therefore the single highest-value target in the AI stack, and it is frequently the newest and least-reviewed code in the deployment.

The architectural conclusion: an AI control plane that stores long-lived provider keys next to its own auth logic offers an attacker a single object worth compromising. A stateless proxy that binds each call to a verified identity and holds no long-lived provider credentials gives the same bypass far less to reach. I go through this in what the LiteLLM CVE wave teaches about control-plane design.

Class 2: multi-tenant isolation failure and secret harvest

Langflow's CVE-2026-55255 is a CVSS 9.9 cross-tenant insecure direct object reference that lets an attacker read other tenants' embedded secrets, including LLM provider keys, cloud credentials, and database secrets. Help Net Security reported active exploitation on July 8, 2026, and CISA ordered federal civilian agencies to mitigate by July 10 (Help Net Security).

The severity comes from what the tool was storing rather than from the IDOR itself, which is an ordinary web bug. AI orchestration tools accumulate long-lived provider keys because that is how they were designed to work, and they hold them adjacent to multi-tenant data. Any isolation flaw in that shape converts directly into wholesale provider-key theft.

Class 3: pre-auth RCE in orchestration and notebook tooling

CVE-2026-39987 in marimo, versions up to 0.20.4, gave attackers pre-authentication remote code execution, and the reported incidents show them harvesting AWS keys and then operating the LLM itself as a post-exploitation tool against Secrets Manager (The Hacker News). Sysdig's JadePuffer disclosure on July 1, 2026 documented an LLM agent entering through a Langflow RCE, CVE-2025-3248, and a Nacos auth bypass, then running recon, credential theft, lateral movement, and database extortion without a human in the loop (Sysdig).

The shared trait: these products began life as developer tools. A notebook server that executes arbitrary code is behaving correctly. The defect appears when it is exposed to a network it was never designed for, which is what happens when an AI experiment reaches production without a security review.

Class 4: unsafe deserialization in model artifacts

Model weights distributed in Python pickle-backed formats execute arbitrary code on load, by design of the serialization format rather than by bug. A model file downloaded from a public hub and loaded into an inference server is a code-execution primitive wearing a data-file extension. The mitigation has existed for years in the safetensors format, and pickle-backed artifacts remain widely published and widely loaded.

This class is genuinely upstream of the HTTP boundary. Nothing at the request layer inspects a weight file, and any article that claims otherwise is selling something. The controls are artifact provenance, signature verification, format restriction, and isolation of the loading process.

Class 5: configuration-to-command execution by protocol design

The largest single event of 2026 in this category was structural. Researchers disclosed more than 40 CVEs against Model Context Protocol implementations between January and April across the Python, TypeScript, Java, and Rust SDKs, and the CSA and OX Security research note published April 20, 2026 traced the common root to the STDIO interface, where configuration flows directly into command execution regardless of language (CSA Labs). The affected supply chain spans an estimated 150 million downloads and more than 7,000 publicly accessible servers. Individual instances kept the pattern: CVE-2026-33032 in nginx-ui MCP, a CVSS 9.8, was a missing authentication check on the MCP message endpoint for command execution requests.

One architectural decision, taken once, propagated into every implementation that trusted the protocol to be what it appeared to be.

The shared root cause

Read the five classes together and the diagnosis is uncomfortable. The AI infrastructure layer was assembled at startup speed by teams optimizing for capability, then promoted into production networks holding enterprise data and provider credentials. Developer-tool trust assumptions came with it: local execution is fine, configuration is trusted, the operator is the only caller, secrets can live in the workspace.

Patching keeps pace with none of it. Exploitation windows for AI infrastructure now run in hours, with LiteLLM's CVE-2026-42208 exploited roughly 26 hours after advisory and LMDeploy's CVE-2026-33626 in about 13 hours. Prioritization by KEV and EPSS narrows the field, since only around 7% of 2026 CVEs clear real-world exploitability thresholds, and I work through that math in the June 2026 CVE surge and patch prioritization.

What the request boundary compensates for

Precision matters here, because three of the five classes sit outside the HTTP AI traffic boundary.

Classes 3, 4, and 5 are execution defects in servers, artifacts, and local transports. Patching, segmentation, artifact signing, and workload isolation own them. What an enforcement layer at the AI request boundary contributes is narrower and still valuable: an attacker who achieves execution has to reach a model to operate, and an unrecognized in-environment identity making LLM calls that no policy authorizes is a signal that fires during the operation rather than after it. The per-decision record then supplies the forensic account of what the attacker asked the model to do.

Classes 1 and 2 are different. They are defects in the AI control plane itself, and the architecture of that control plane decides how much they are worth. A component holding long-lived provider keys and evaluating its own authentication is the object worth attacking. A stateless proxy that binds every call to an externally verified identity, holds no persistent provider credentials, and writes decisions to an independent store presents a much smaller prize to the same bug.

DeepInspect

This is the problem DeepInspect was built to solve. DeepInspect is a stateless proxy between authenticated users or agents and any HTTP-based LLM endpoint. It carries no long-lived provider keys in a persistent store, binds every request to an identity verified upstream, and evaluates identity, role, prompt classification, and model authorization on each call, permitting, redacting, or denying inline with a fail-closed default.

Every decision writes a signed record committed before the response returns to the calling application. When an attacker who entered through an unpatched inference server starts driving model calls from an identity nobody provisioned for that purpose, the calls are refused by policy and the attempt is recorded by a component the compromised host never had custody of. That is a compensating control against classes 3 through 5 and a reduced attack surface against classes 1 and 2, stated at its real strength.

If your AI infrastructure inventory is currently a spreadsheet and your CVE feed is arriving faster than your patch window, book an AI readiness assessment.