Common Vulnerabilities and Exposure (CVE) systems are the global standard for cataloging software security flaws. Maintained by MITRE and supported by CISA, the program gives each vulnerability a unique ID and description that allows developers, vendors and defenders to communicate clearly and act quickly against known risks.
When the AI model becomes a core component of an enterprise system, the security community is asking: Should CVE systems also be applied to the model? The AI model exposes new failure modes, by-product prompts, poisoned training data, and data leaks. This may seem like a vulnerability, but does not conform to the CVE definition. According to CVE policy, vulnerabilities must be a weakness in a product that violates confidentiality, integrity, or availability guarantees.
In most cases, assigning CVEs to individual models is incorrect. Actual vulnerabilities lie in frameworks and applications that load and use those weights. The model is a parameterized mathematical system. Binary facts loaded into frameworks that provide APIs, tools, and business logic. The vulnerability lives in the surrounding code, not static weight files, but session management, data processing, framework serialization, and more.
In this post, I outline why CVEs generally need to scope to applications and frameworks rather than AI models.
When CVE is proposed for the model, what does it explain?
The most proposed AI model CVE falls into three categories:
- Application or framework vulnerabilities: A software issue wrapping or serving the model, not the model itself. Example: Processing or framework-level defects for insecure sessions (eg, Tensorflow CVE).
- Supply Chain Issues: Risks such as tampered weights, poison data sets, or compromised reports. These are most often tracked by supply chain security mechanisms, not CVE.
- Statistical Behavior of the Model: Intrinsic properties such as data storage, bias, or hostile sensitivity. These are not vulnerabilities defined by CVE, but need to be mitigated in application design.
Consider the case of blind SQL injection. The defect lies in applications that have failed to sanitize the query, not in SQL databases. Blind SQL injection allows attackers to create queries to remove sensitive data one at a time, even though the database is working as designed. The vulnerability lies not in the database itself, but in applications that expose raw query access.
Hostile and inference time attacks on AI models follow the same pattern. The model is performing inference as designed, but the surrounding applications do not control access or detect malicious queries. If necessary, any CVE should be published for that application layer, not for the model weight.
How do different classes of attacks on AI models align and align with CVE criteria?
AI models are software artifacts, but their stochastic nature introduces behaviors that appear to be vulnerable. Most of these are normal inference results exploited in the context of an insecure application.
Two questions are important when assessing whether CVE should be applied.
- Has the model failed its intended inference function in a way that violates the security properties?
- Is this problem specific to this model instance so that it helps users identify and fix it, rather than simply representing the class of attacks that CVE ID applies to all models?
In almost all cases, the answer to both questions is no. Models with unlimited access can be exposed to extraction, inference, adversarial queries, or addiction. These are the characteristics of machine learning systems as classes and are not flaws in a particular model instance. Issuing a CVE here does not add any practical values. It states that the AI model is susceptible to known attack families.
CVEs exist to track individual, modifiable weaknesses. Most AI attack technologies exploit one of the following:
- Normal inference behavior, The model maps the input to the output in a way that could expose statistical artifacts.
- System design flaws, If your application exposes a model without access control, query monitoring, or output filtering.
Labeling these as “model vulnerabilities” reduces the purpose of CVE. The appropriate scope is frameworks, APIs, and applications where available weaknesses are living.
The following attack class shows why. They are often proposed as reasons to issue CVEs to models, but in practice they are tailored to the security of the application and supply chain. One gray area is an intentional training data addiction and can create reproducible, model-specific compromises.
How does an attacker extract the weights of a model and reproduce the behavior of the model? Is it a vulnerability?
These attacks aim to extract the weights of the model or replicate the behavior of the model without approval. Examples include model stealing, partial weight extraction, and the following token distribution replay: The root cause is mostly overly detailed output, such as unlimited queries or exposed logits. The model itself performs normal inference. The weakness lies in access control and output processing by applications or services.
When a model leaks information about training data, does it constitute a CVE?
Here, the attacker is trying to reveal sensitive information from the training set. The technique involves membership inference to predict whether records are being used in training, and reconstructing the data that guides the model to play back the stored samples. These attacks exploit overfitting and trust leakage through carefully crafted inputs. Again, the model is working as expected. Mitigations such as discriminatory privacy and query monitoring must be applied at the system level.
Do adversarial inputs that force misclassifications create model vulnerabilities or system flaws?
These attacks force misclassification or unnecessary output by manipulating inputs. In vision, unperceptible perturbations can flip labels (e.g., stop signs to speed limit signs). In language, the jailbreak prompt can bypass the control. Generation models can lead to unauthorized production of content through hostile prompts. The model applies the trained parameters. The failure is that the application does not detect or constrain adversarial queries.
If malicious code is executed while loading the model, is the model itself a fault?
Many so-called “model attacks” are attacks on the framework or format used to load and serviculate models. Examples include pickle starrierization exploits that allow remote code to be executed, or lambda layer payloads with malicious code embedded in the forward pass. These issues are caused by insecure serialization formats and framework flaws. The model itself is not related. When converted to a secure format or switching framework, the risk is removed and CVE belongs to the framework rather than the weight of the model.
When do addiction training data create a background model that may guarantee CVE?
This category represents one edge case where the CVE may have a value. By injecting malicious samples during training, an attacker can embed backdoor or target behavior into the model itself. For example, an image classifier may incorrectly label input with hidden triggers. Alternatively, the language model may be biased by poisoned prompts. In these cases, the model was compromised during training, and the poisoned weight is an individual trackable artifact. While many incidents are better addressed as supply chain issues through data origin and reliability checks, intentionally, background models may guarantee CVE-level tracking.
Where should you apply CVE and how should you track AI-specific risks?
Creating a CVE ID serves a specific purpose. It is a vulnerability that allows developers and security teams to track and communicate exploitable vulnerabilities in software components, allowing them to triage, prioritize and repair risks.
The AI model does not fit into this range. Most attacks take advantage of the expected inference behavior or weaknesses of software that serves the model. Issuing a CVE at the model level adds noise without providing practical guidance.
The correct scope of CVE is the framework and application that loads and exposes models. It is where exploitable conditions exist, where patches and mitigations can be applied. One narrow exception is intentional training data addiction that embeds reproducible backdoors in a particular weight file, but even this is better addressed through supply chain integrity mechanisms.
The forward path is clear. Apply CVEs to promote actual repairs and strengthen the surrounding ecosystem with supply chain guarantees, access control and monitoring. Rather than cataloging all statistical properties as vulnerabilities, AI security relies on the defense of systems that wrap and serve models.
For more information about Nvidia's AI Red team, visit the Nvidia AI Red Team: Introduction | Nvidia Technical Blog. To report potential security vulnerabilities in your NVIDIA products, please complete the security vulnerability submission form or email psirt@nvidia.com.
