AI Vulnerability Intelligence: Triage for Models and Frameworks

AI vulnerability intelligence starts with a concrete question: what asset is actually vulnerable, and is that asset reachable in this deployment? A CVE, GitHub advisory, model disclosure, or vendor bulletin is a set of claims to map to your environment—not an automatic finding that every AI system is exposed. Good triage preserves uncertainty, assigns ownership, and produces evidence that a fix really reached the running system.

Classify the asset before judging urgency

An AI stack can contain a local model artifact, model runtime, framework or library, inference server, orchestration framework, parser, plugin, tool integration, hosted API, container image, or transitive dependency. The same product name may describe a managed service in one team and a pinned package in another. A vulnerability in a parser does not automatically apply to a hosted model that never uses that parser.

Separate five categories that are often mixed together:

• Model behavior: an unsafe or unreliable learned response. The mitigation may be evaluation, prompting, policy, or product design rather than a software patch.
• Software vulnerability: a flaw in code such as an inference server, parser, or API that can violate a security property.
• Service configuration weakness: an exposed endpoint, permissive setting, or missing boundary in an otherwise patched product.
• Dependency vulnerability: a flaw in a direct or transitive package that your application actually loads.
• AI application design flaw: missing authorization, unsafe tool handling, or data-boundary logic created by your integration.

The category determines evidence, patch owner, version matching, and the kind of remediation that is possible. Model security is a useful companion when the concern is an artifact or loader; AI supply-chain security covers provenance across dependencies and build inputs.

Evidence-led triage pipeline

PERMSAI AI VULNERABILITY TRIAGE PIPELINE

ADVISORY ↓ IDENTIFY ASSET ↓ VERIFY SOURCE ↓ MATCH PRODUCT / PACKAGE / MODEL ↓ MATCH VERSION ↓ MATCH CONFIGURATION ↓ ESTABLISH REACHABILITY ↓ CHECK PREREQUISITES ↓ ASSESS IMPACT ↓ CHECK EXPLOITATION EVIDENCE ↓ IDENTIFY FIX / MITIGATION ↓ TEST APPLICABILITY ↓ PRIORITIZE ↓ REMEDIATE ↓ VERIFY CLOSURE

Treat each arrow as a recorded decision. “Likely affected” is a valid intermediate state when identity or configuration evidence is incomplete. Do not collapse unknowns into either safe or critical merely to close a ticket.

Verify the source and its claims

Start with the vendor or upstream project security advisory for product-specific facts. A CVE Record provides a durable identifier and structured description; the CVE Numbering Authority (often a vendor or project) is the original publishing authority for that record. NVD may add enrichment such as severity vectors, weaknesses, and references, but it is not necessarily the primary source for affected versions or exploit conditions.

CISA’s Known Exploited Vulnerabilities catalog adds a different signal: inclusion means the catalog’s criteria for known exploitation were met. That can materially raise urgency. Absence from KEV is not evidence that exploitation is impossible or that a vulnerability is safe. GitHub Security Advisories are valuable for package ecosystems because they often connect affected and patched ranges to an upstream repository, but they should be reconciled with the maintainer’s advisory.

Capture publication date, last update, references, and the exact claims made. A social post, issue comment, or unverified scanner result can be a lead, not confirmation. Preserve the source URL and the date your team reviewed it because advisories can change.

Establish product, package, and model identity

Resolve the exact vendor or project, package name, component, runtime, deployment mode, model identifier, and feature configuration. Compare the advisory with a software bill of materials, lockfile, container digest, image inventory, and runtime telemetry where available. A fork may have backported a fix without changing the upstream version string. Conversely, a vendored copy or a transitive dependency may be present even when the package is absent from the top-level manifest.

Managed services require a different question. If the provider controls patch deployment, record the service region, model or API version, provider advisory, and status communication. Customer actions may be a feature disablement, network restriction, credential rotation, or provider confirmation rather than a local package upgrade. Do not claim remediation merely because a provider says a fix is rolling out; capture the confirmation and the effective date.

Read version ranges carefully

Extract introduced versions, affected ranges, fixed versions, and backported releases exactly as published. Check all maintained branches and compare the deployed artifact, not only a source repository’s latest tag. Semantic versioning is useful but cannot prove exposure when vendors patch downstream builds, distributions rename packages, or a container embeds a different commit.

If a fix is available only in a newer major branch, evaluate compatibility and compensating controls while the upgrade is prepared. A version that appears newer may still carry the vulnerable code if a distribution reverted a patch or a fork diverged. Record the evidence that connects the running process to the version decision.

Configuration and reachability are separate checks

Many advisories require a specific endpoint, parser, plugin, optional dependency, authentication mode, network exposure, or deployment setting. An installed package is not proof that the vulnerable path is enabled. Conversely, a disabled UI feature may still be reachable through an API or background worker.

Ask whether untrusted input can reach the component, whether the feature is enabled, and whether the endpoint is externally accessible. Identify authentication, privilege, network-position, file, model, or user-interaction prerequisites. A trusted boundary that blocks a path is useful evidence, but do not use “behind a firewall” as a substitute for checking actual routes, egress, and internal callers.

Prerequisites

Map whether exploitation requires remote or local access, authentication, a particular privilege, network adjacency, user interaction, a crafted file, a model or tool setting, or another prerequisite. Then ask whether untrusted input can reach the component through your routes and integrations.

Do not use “behind a firewall” as a universal dismissal. A trusted internal worker, support endpoint, or tenant-specific route may still accept untrusted content. Conversely, a well-enforced boundary can reduce local exposure while remediation is prepared. State the evidence and the remaining uncertainty rather than converting a prerequisite into “safe.”

Assess impact without guessing

Map demonstrated impact to confidentiality, integrity, availability, code execution, credential exposure, cross-tenant access, SSRF, file access, or resource exhaustion. Read what the advisory or patch actually supports; do not infer remote code execution from a dramatic title. A model behavior that reveals sensitive text may require data-flow and authorization fixes even when no CVE exists. Threat modeling helps connect an advisory to the assets and boundaries that matter locally.

Prerequisites change local priority without erasing severity. An unauthenticated internet-facing path deserves faster action than an authenticated administrative endpoint on an isolated network, but both should remain tracked with clear rationale.

Evidence confidence ladder

Level	Operational meaning	Typical evidence	Triage treatment
CONFIRMED	Asset, version, configuration, reachability, and impact match authoritative evidence	vendor advisory plus deployed-version and path proof	prioritize and remediate now
STRONG	Most conditions match; one material detail awaits validation	primary advisory, inventory, credible technical analysis	contain while validating; assign owner
PARTIAL	Some identity or impact evidence exists but applicability is unclear	CVE/NVD metadata, issue, scanner, incomplete inventory	investigate; do not claim safe or affected
UNVERIFIED	Claim lacks reliable corroboration	social post, unsubstantiated report, ambiguous scanner	monitor source; no risky remediation assumptions

Evidence is not a severity score. A high CVSS item with no reachable path may be lower local priority than a moderate flaw on a public, privileged endpoint. Conversely, a low score does not excuse missing tenant isolation or credential controls.

Prioritize with context, not CVSS alone

Use applicability, reachability, business exposure, prerequisites, impact, known exploitation, public technical evidence, asset criticality, available fix, and compensating controls. AI security controls matrix can map preventive, detective, responsive, and verification measures around the affected boundary.

Avoid inventing a universal formula that hides judgment. Instead, write a short decision record: what is known, what is unknown, who owns the asset, which users or tenants are exposed, what evidence raises or lowers urgency, and when the decision will be revisited.

Choose remediation and temporary mitigation

Full remediation may be an upgrade, patched image, package removal, provider-side fix, or corrected application code. Temporary mitigation can disable a parser or endpoint, restrict network access, add authentication, isolate a worker, rotate a credential, narrow tool permissions, or add monitoring. Label mitigations as temporary and define an expiry or follow-up; a firewall rule does not replace patching when the vulnerable component remains reachable elsewhere.

For model-file concerns, quarantine the artifact, verify provenance and hash, and test the loading path. Unsafe deserialization is a software execution boundary; it is not the same as a model producing an undesirable answer. For framework findings, confirm direct versus transitive dependency, the loaded feature, the actual runtime version, and container contents before selecting the owner.

Verify closure in the running environment

After remediation, confirm the deployed version or digest, effective configuration, route exposure, and relevant feature behavior. Retest the security property using safe, non-destructive checks. Update the inventory, attach the advisory and verification evidence, and record remaining compensating controls. A ticket marked “patched” is not closure if the old container is still serving traffic, a worker uses a separate dependency tree, or a managed provider has not confirmed the change.

AI vulnerability applicability matrix

Question	Evidence	PASS condition	FAIL or UNKNOWN consequence
Asset identity	product, package, model, component owner	exact asset is mapped	route to inventory owner; do not assume scope
Version	lockfile, digest, runtime query, provider notice	deployed version is in or out of range	contain and validate the running artifact
Configuration	feature flags, endpoint, plugin, auth mode	required vulnerable path state is known	disable or isolate while investigating
Reachability	routes, callers, network and tenant boundaries	untrusted input cannot reach, or reachability is proven	treat as potentially exposed
Prerequisite	authentication, privilege, file, network, interaction	prerequisite is evidenced	raise uncertainty and test safely
Impact	advisory, patch, credible research	demonstrated impact maps to local assets	avoid title-based conclusions
Exploitation evidence	KEV, incident, PoC, telemetry	claim is classified by confidence	monitor and preserve evidence
Fix	vendor patch, release, workaround	a documented remediation exists	assign mitigation and owner
Local verification	deployment and regression test	running path no longer matches flaw	keep open; ticket status is insufficient

Practical triage checklist

• Preserve the advisory, publication/update date, references, and review date.
• Identify the exact model, runtime, package, parser, service, image, and owner.
• Compare deployed versions and configuration, including forks, backports, and managed services.
• Prove whether untrusted input can reach the named feature and what prerequisites apply.
• Separate model behavior, software flaws, configuration weaknesses, dependencies, and design flaws.
• Classify evidence as confirmed, strong, partial, or unverified.
• Use CVSS and KEV as context, never as a replacement for local applicability.
• Choose a full fix and clearly labeled temporary mitigations.
• Retest the running deployment, update inventory, and attach closure evidence.

Focused triage paths

Apply this workflow to AI Tool SSRF, Container and Sandbox Escapes, LLM Framework Dependencies, Malicious Models and Repository Trust, and AI Vulnerability Reports.

Sources

CVE Program, NVD, CISA KEV Catalog, GitHub Security Advisories, and vendor or upstream project advisories establish the evidence hierarchy. The triage pipeline, confidence ladder, and applicability matrix are PermsAI’s operational synthesis.