CVSS for AI Vulnerabilities: Uses and Limits

CVSS is useful for describing the technical severity of a vulnerability, but it is not a complete answer to whether an AI system needs immediate remediation. A model-serving gateway, inference runtime, notebook image, vector database, or agent dependency can carry a CVSS score; the score does not by itself prove that the component is deployed, reachable, exploitable in your configuration, or important to your business. Security teams get better decisions when they preserve the original vector and add local evidence about the AI stack.

What CVSS is designed to answer

The Common Vulnerability Scoring System (CVSS) is a standardized way to communicate characteristics and severity of a vulnerability. FIRST’s current specification is CVSS 4.0. It separates metrics into Base, Threat, Environmental, and Supplemental groups. Base metrics describe intrinsic characteristics of the vulnerability. Threat metrics capture time-varying conditions such as exploit maturity. Environmental metrics let a consumer account for its own deployment, mitigations, and asset importance. Supplemental metrics add context without changing the final score.

That structure is valuable because it makes a severity claim inspectable. A score should travel with its vector, source, version, publication date, and affected component. A bare number copied into a ticket is difficult to reproduce and easy to misapply. A CVSS 4.0 vector begins with CVSS:4.0/ and records the selected metric values in a defined order. Preserve that string even when your ticketing system also displays a qualitative label.

CVSS is not a probability of compromise, a patch deadline, a measure of exploit activity, or a substitute for vulnerability management. FIRST recommends enriching the Base score with Threat and Environmental context and using the result inside a broader process. Regulatory, customer, monetary, and reputational consequences are outside the CVSS calculation and must be assessed separately.

Reading a CVSS 4.0 result in an AI stack

Start with the advisory, not the score. Identify the vulnerable product, component, version range, fixed version or backport, and the vulnerability type. Then read the vector. CVSS 4.0 Base metrics include attack vector, attack complexity, attack requirements, privileges required, user interaction, and impacts to vulnerable and subsequent systems. Those dimensions can clarify whether a flaw in a model API, plugin, parser, or orchestration service is remotely reachable and what kinds of confidentiality, integrity, or availability impact are technically possible.

Threat metrics can change as public evidence develops. Exploit maturity is not the same as a vendor’s statement that exploitation is theoretically possible. Environmental metrics are where your architecture matters: an internal inference worker behind a gateway is different from an internet-facing management endpoint, even when the vulnerable package is identical. Record the assumptions used for any environmental adjustment instead of silently replacing the published Base score.

Why the number is not your AI risk decision

AI systems add context CVSS does not know. A high score in an unused development image may be less urgent than a medium score in a reachable document parser that processes every tenant’s uploads. A vulnerable component may be present but disabled; a lower-scored issue may be exposed through a public API, connected to privileged tools, or positioned on a cross-tenant data path.

Check at least five questions before prioritizing:

1. Applicability: Does the affected component and version actually exist in the deployed model, framework, image, plugin, or service?
2. Reachability: Can an attacker reach the vulnerable code through the routes, tools, jobs, or management planes that are enabled?
3. Prerequisites: Are the required privileges, configuration, feature flags, or user interactions present?
4. Impact path: Could compromise reach prompts, retrieval data, credentials, tool actions, tenants, or only an isolated test workload?
5. Response options: Is a patch available, can the feature be disabled, or are compensating controls effective while owners prepare a fix?

These questions complement, rather than replace, the CVSS vector. See PermsAI’s AI vulnerability intelligence triage and AI security advisory reading guide for evidence collection.

CVSS-TO-AI CONTEXT BRIDGE

Question	CVSS helps?	Additional evidence needed	Decision use
Technical severity	Yes: Base metrics and score	Reproduce the affected behavior and confirm the vector source	Compare technical seriousness consistently
Version applicability	Partly: advisory scope may identify versions	SBOM, image digest, lockfile, runtime inventory, and backport evidence	Mark affected, not affected, or unknown
Reachability	Partly: Attack Vector and prerequisites provide clues	Routes, network paths, feature flags, authentication, and exposure tests	Set exposure priority
Asset criticality	Environmental metrics can reflect local criticality	Service tier, tenant data, recovery needs, and business owner	Rank remediation work
Known exploitation	Threat metrics describe exploit maturity	CISA KEV, vendor notices, detections, and incident evidence	Escalate active-risk cases
Tenant exposure	Not directly	Data-flow and authorization tests across tenants	Require isolation fixes or containment
Compensating controls	Environmental metrics can document mitigations	Gateway rules, segmentation, disabled features, and monitoring	Choose temporary treatment
Fix availability	No	Vendor patch, supported backport, upgrade path, or disablement plan	Set a concrete owner and due date

AI-specific interpretation without inventing a new score

CVSS describes a software vulnerability, not whether a model is biased, hallucinates, or follows an unsafe instruction. A prompt-injection behavior may be a product boundary failure, an application authorization defect, or a model limitation; do not assign a CVSS score merely because output is undesirable. Conversely, a conventional CVE in a web framework, identity library, container runtime, GPU driver, parser, or vector service can be highly relevant to an AI deployment.

For model and inference infrastructure, map the vulnerable code to the actual execution path. Is the issue in a public API, a queue worker, a notebook image, a Kubernetes admission component, a retrieval connector, or a developer-only tool? Capture model-provider responsibility separately when the component is managed. Customers may need to request provider confirmation, apply a configuration mitigation, restrict network access, rotate exposed credentials, or temporarily disable a feature rather than patching provider internals.

AI VULNERABILITY PRIORITIZATION OVERLAY

The following is a PermsAI operational workflow, not an alternative CVSS standard:

Advisory → Applicability → CVSS/vector → Exposure/reachability → Known exploitation → Asset/business importance → Compensating controls → Remediation decision

At each arrow, attach evidence. Applicability can be an SBOM record and image digest. Reachability can be a route review and an authenticated network test. Known exploitation can be a dated CISA KEV or vendor statement, while local telemetry may show that your own endpoint was contacted. Business importance belongs to the service owner, not the model.

A practical decision record should preserve the published CVSS Base score and vector, any Threat or Environmental calculation, the evidence date, the affected asset identifier, and the resulting treatment: patch, upgrade, isolate, disable, monitor, or accept with an owner and review date. “Patched” is not closure until the deployed artifact, running version, and relevant configuration are verified.

Worked review example

Suppose an advisory reports a remote vulnerability in a Python package used by an inference gateway. The published Base score and vector describe the flaw’s intrinsic conditions, but your review still needs the gateway image digest, package version, enabled endpoint, ingress path, and service identity. If the gateway accepts unauthenticated file conversions, reachability and impact may be greater than a worker that receives only authenticated queue jobs. If a network policy blocks outbound access and the vulnerable feature is disabled, those are meaningful compensating controls, but they should be recorded with an owner and expiry date. A retest should exercise the real deployed path, not only a clean laboratory package. This evidence-driven approach prevents both panic-driven patching and false reassurance.

Common mistakes

• Treating a high score as proof that your instance is exploitable.
• Dropping the vector and retaining only a severity label.
• Assuming a private hostname means a component is unreachable.
• Using model-generated inventory or a prompt assertion as evidence of installed versions.
• Treating a vendor’s fixed version as proof that every deployment received the fix.
• Confusing CVSS with CISA KEV, a proof of compromise, or a business-risk score.

Practical review checklist

• Record the advisory URL, CVE, component, version range, fixed version, CVSS version, vector, score, source, and date.
• Reconcile the claim with your SBOM, image digests, runtime inventory, and configuration.
• Trace network reachability, authentication, tenant boundaries, tool paths, and management access.
• Check current exploit evidence, including CISA KEV and vendor notices, without treating absence as safety.
• Document asset criticality, compensating controls, and owner-approved treatment.
• Retest after patching or mitigation; retain before/after evidence and the deployed artifact identity.

Sources

• FIRST CVSS v4.0 Specification
• FIRST CVSS Consumer Implementation Guide
• NVD vulnerability data
• CVE Program
• CISA Known Exploited Vulnerabilities Catalog

CVSS is most effective when it makes a technical claim transparent and your local evidence makes the operational decision accountable. Use the score to start a disciplined conversation about the AI system’s real exposure, not to end it.