The Common Vulnerabilities and Exposures (CVE) system is the global standard for cataloging security flaws in software. Maintained by MITRE and backed by CISA, the program gives each vulnerability a unique ID and description for developers, vendors, and defenders to communicate clearly and act quickly on known risks.
As AI models become core components of enterprise systems, the security community is asking: should the CVE system also apply to models? AI models expose new failure modes‚adversarial prompts, poisoned training data, and data leakage—that look like vulnerabilities but don’t fit the CVE definition. According to CVE policy, a vulnerability must be a weakness in a product that violates a confidentiality, integrity, or availability guarantee.
In most cases, assigning a CVE to an individual model is the wrong scope. The real vulnerabilities sit in the frameworks and applications that load and use those weights. Models are parameterized mathematical systems: binary artifacts loaded into frameworks that provide APIs, tooling, and business logic. Vulnerabilities live in the surrounding code, such as session management, data handling, or framework serialization, not in the static weight files.
In this post, we outline why CVEs should generally be scoped to applications and frameworks, not to AI models.
When a CVE is proposed for a model, what is it describing?
Most proposed AI model CVE fall into three categories:
- Application or framework vulnerabilities: Issues in the software that wraps or serves the model, not in the model itself. Example: insecure session handling or framework-level flaws (e.g., TensorFlow CVEs).
- Supply chain issues: Risks such as tampered weights, poisoned datasets, or compromised repos. These are best tracked with supply chain security mechanisms, not CVEs.
- Statistical behaviors of models: Inherent properties like data memorization, bias, or adversarial susceptibility. These aren’t vulnerabilities by CVE’s definition and must be mitigated in application design.
Consider the case of blind SQL injection: the flaw isn’t in the SQL database but in the application that fails to sanitize queries. With blind SQL injection, an attacker can craft queries to exfiltrate sensitive data one bit at a time, even though the database is functioning exactly as designed. The vulnerability lies in the application exposing raw query access, not in the database itself.
Adversarial and inference-time attacks against AI models follow the same pattern. The model is performing inference as designed, but the surrounding application fails to control access or detect malicious queries. Any CVE, if appropriate, should be issued against that application layer, not the model weights.
How do different classes of attacks on AI models align, or fail to align, with CVE criteria?
AI models are software artifacts, but their probabilistic nature introduces behaviors that look like vulnerabilities. Most of these are normal inference outcomes exploited in unsafe application contexts.
When evaluating whether a CVE should apply, two questions matter:
- Has the model failed its intended inference function in a way that violates a security property?
- Is the issue unique to this model instance such that a CVE ID would help users identify and remediate it, rather than simply restating a class of attacks that apply to all models?
In almost all cases, the answer to both questions is no. Any model with unrestricted access can be subjected to extraction, inference, adversarial queries, or poisoning. These are properties of machine learning systems as a class, not flaws in a specific model instance. Issuing a CVE here adds no actionable value; it only restates that AI models are susceptible to known attack families.
CVEs exist to track discrete, fixable weaknesses. Most AI attack techniques exploit either:
- Normal inference behavior, where models map inputs to outputs in ways that may expose statistical artifacts.
- System design flaws, where applications expose the model without access control, query monitoring, or output filtering.
Labeling these as “model vulnerabilities” dilutes the purpose of CVEs. The proper scope is the frameworks, APIs, and applications where exploitable weaknesses live.
The following attack classes show why. They are often proposed as reasons to issue CVEs for models, but in practice, they align with application and supply chain security. The one gray area is deliberate training data poisoning, which can create a reproducible, model-specific compromise.
How do attackers extract model weights or replicate model behavior, and is that a vulnerability?
These attacks aim to extract model weights or replicate model behavior without authorization. Examples include model stealing, partial weight extraction, and next-token distribution replay. The root cause is almost always unrestricted queries or overly detailed outputs, such as exposed logits. The model itself performs normal inference. The weakness lies in access control and output handling by the application or service.
When models leak information about training data, does that constitute a CVE?
Here, the attacker seeks to reveal sensitive information from the training set. Techniques include membership inference, which predicts whether a record was used in training, and data reconstruction, which induces the model to regenerate memorized samples. These attacks exploit overfitting and confidence leakage through carefully crafted inputs. Again, the model is behaving as expected. Mitigations such as differential privacy or query monitoring must be applied at the system level.
Do adversarial inputs that force misclassification create a model vulnerability or a system flaw?
These attacks force misclassification or unwanted outputs by manipulating inputs. In vision, imperceptible perturbations can flip labels (for example, a stop sign to a speed limit sign). In the language, jailbreak prompts can bypass controls. Generative models can be steered into producing disallowed content through adversarial prompting. The model applies its parameters as trained. The failure is that the application does not detect or bound adversarial queries.
If malicious code executes during model loading, is the model itself at fault?
Many so-called “model attacks” are attacks on the frameworks or formats used to load and serve models. Examples include pickle deserialization exploits that enable remote code execution, or lambda-layer payloads that embed malicious code in the forward pass. These issues stem from insecure serialization formats and framework flaws. The model itself isn’t implicated. Converting to a safe format or switching frameworks removes the risk, and any CVE belongs to the framework, not the model weights.
When does poisoned training data create a backdoored model that might warrant a CVE?
This category represents the one edge case where a CVE may have value. By injecting malicious samples during training, an attacker can implant backdoors or targeted behaviors into the model itself. For example, an image classifier may mislabel inputs with a hidden trigger, or a language model may be biased through poisoned prompts. In these cases, the model is compromised during training, and the poisoned weights are a discrete, trackable artifact. While many incidents are better addressed as supply chain issues through data provenance and authenticity checks, deliberately backdoored models may warrant CVE-level tracking.
Where should CVEs be applied, and how should AI-specific risks be tracked?
The creation of CVE IDs serves a specific purpose: tracking and communicating about exploitable vulnerabilities in software components, for developers and security teams to triage, prioritize, and remediate risk.
AI models don’t fit this scope. Most attacks exploit expected inference behavior or weaknesses in the software that serves the model. Issuing CVEs at the model level adds noise without delivering actionable guidance.
The correct scope for CVEs is the frameworks and applications that load and expose models. That is where exploitable conditions exist, and where patches and mitigations can be applied. The one narrow exception is deliberate training data poisoning that implants reproducible backdoors in specific weight files, but even this is often better addressed through supply chain integrity mechanisms.
The path forward is clear: apply CVEs where they drive real remediation, and strengthen the surrounding ecosystem with supply chain assurance, access controls, and monitoring. AI security depends on defending the systems that wrap and serve models, not on cataloging every statistical property as a vulnerability.
To learn more about NVIDIA’s AI Red Team: NVIDIA AI Red Team: An Introduction | NVIDIA Technical Blog. To report a potential security vulnerability in any NVIDIA product, please fill out the security vulnerability submission form or email psirt@nvidia.com.
