ML Model CVE Tracking: How to Monitor Your AI Stack

If you searched for ml model cve tracking, you probably already suspect the uncomfortable part: the CVE process was designed for software packages, and much of your ML attack surface is not a software package. The cautionary tale is CVE-2023-48022, a CVSS 9.8 remote code execution flaw in Anyscale Ray’s job submission API. The vendor disputed it as intended behavior, no patch shipped for the original report, and attackers exploited exposed clusters anyway. MITRE now catalogs that activity as Campaign C0045 (ShadowRay), running from September 2023 to March 2024, and calls it the first known instance of AI workloads being actively exploited in the wild through AI infrastructure vulnerabilities. A tracking program that filtered out DISPUTED entries would have missed the single most consequential ML infrastructure vulnerability of that period.

So the job is twofold: track the CVEs that do exist across your ML stack, and know exactly where the CVE system stops covering you.

What a CVE covers in an ML stack, and what it doesn’t

Map your stack into layers, because the CVE coverage is wildly uneven across them.

Frameworks and training tooling. PyTorch, TensorFlow, MLflow, Ray, Kubeflow. This layer is well inside CVE territory and the record is ugly: experiment trackers and orchestration tools were built for trusted internal networks, then deployed on the open internet. The recurring bug classes are unauthenticated APIs, path traversal, and unsafe deserialization. Treat any ML tool with a web UI as an attack surface, not a dashboard.

Inference and serving. Ollama, vLLM, Triton, TorchServe, llama.cpp. Also CVE territory, and moving fast because these components increasingly sit at the network edge. CVE-2024-37032 is representative: Ollama before 0.1.34 failed to validate that a model digest was a well-formed SHA-256 string, so a crafted digest containing traversal sequences could reach files outside the model directory. That is a boring, classic CWE-22 bug. It just happens to live in the component you pointed at a registry that pulls attacker-influenceable model manifests.

Model artifacts. Here the CVE model degrades. A pickle-serialized checkpoint that executes code on load is behaving as designed, so there is usually no CVE to track. There is no CPE naming scheme for “the weights file some contractor uploaded to your internal registry.” Vulnerable-by-design formats occasionally earn advisories against the loader, not the artifact. Your control here is artifact scanning and format policy (prefer safetensors, quarantine pickle), not feed monitoring.

Model behavior. Prompt injection, jailbreaks, extraction, poisoning. Almost never CVE-tracked, because a jailbreak is not a flaw in a specific product version with a patch. This is the layer where you need supplementary databases, covered below. For the offensive mechanics themselves, aisec.blog covers prompt injection and agent exploitation in depth; none of it will ever page your CVE feed.

Where to actually watch: feeds and databases

NVD and CVE.org, filtered by CPE watchlist. Build an explicit inventory of your ML components (framework, serving runtime, experiment tracker, vector database, orchestration layer) and query the NVD API against it on a schedule. Generic keyword alerts on “machine learning” produce garbage; CPE-pinned queries produce signal. The catch is that new ML projects often have no CPE assigned for months, so pair this with the next two feeds.

huntr. huntr is Protect AI’s bug bounty platform focused specifically on the open source AI/ML supply chain, and it operates as a CVE Numbering Authority. A large share of recent MLflow, Ray-ecosystem, and inference-server CVEs originated there, which means the huntr disclosure often carries the reproduction detail the NVD entry lacks. If you run open source ML tooling, read the advisories for your components directly rather than waiting for downstream scanner coverage.

GitHub Security Advisories. ML projects patch fast and paper-trail slowly. A GHSA frequently exists days or weeks before the NVD entry is enriched with severity and CPE data. Subscribe to advisories on the specific repos you deploy.

AVID and MITRE ATLAS for the non-CVE layer. AVID catalogs AI system failure modes with evidence and reproducible evaluation detail, covering the model-behavior territory CVE ignores. MITRE ATLAS gives you the adversary-side view: tactics and techniques for attacks against AI systems, with real case studies. Neither replaces CVE tracking; both cover what it structurally cannot.

For cross-checking whether a disclosure actually turned into an incident, the running tracker at ai-alert.org correlates ML CVEs with breach and exploitation reports, which is the question your leadership will actually ask.

Build a workflow that survives disputed CVEs

Five concrete moves, in priority order:

1. Inventory before feeds. You cannot track CVEs for components you have not enumerated. Pull the ML bill of materials out of your training and serving environments first: every framework, server, tracker, and their versions. If your MLOps platform already exports this (the same inventory that drift monitoring needs, as covered at sentryml.com), reuse it.
2. Never filter out DISPUTED. ShadowRay is the proof case. Route disputed entries affecting your inventory to a human, and read the dispute text itself. Anyscale’s position, quoted in the NVD record, was that Ray is not intended for use outside a strictly controlled network environment. That sentence is not a dismissal; it is a deployment requirement you must verify you meet.
3. Treat “internal tool” claims as exposure hypotheses to test. Scan your own perimeter for MLflow, Ray dashboards, Ollama APIs, and Jupyter. The exploited ShadowRay clusters were not zero-days; they were internet-exposed instances of a tool everyone assumed was internal.
4. Gate model artifacts separately from packages. Dependency scanners will not flag a malicious checkpoint. Add artifact scanning and a serialization-format allowlist to the model registry ingest path, because no feed will alert you there. Which formats belong on that allowlist, and why, is worked through in model file format security.
5. Patch serving infrastructure on application-tier SLAs, not data-science-tier ones. An inference endpoint is a production network service. The Ollama fix for CVE-2024-37032 existed in 0.1.34; the exposure window for any given org was defined entirely by their own upgrade lag. The full runtime record for vLLM, Ollama, llama.cpp and Triton is in inference server CVEs, and it is now the fastest-growing part of the ML CVE corpus.

The honest summary: CVE tracking covers the software layers of your ML stack well, the artifact layer barely, and the behavior layer not at all. Track NVD and huntr against a real inventory, refuse to auto-dismiss disputed entries, and cover the gaps with AVID, ATLAS, and your own artifact gates.

Related across the network

• Adversarial Examples vs. Data Poisoning: Timing Is Everything — adversarialml.dev
• Adversarial Robustness in NLP: Why Text Attacks Are Different — adversarialml.dev
• Adversarial Training Best Practices That Survive Evaluation — adversarialml.dev
• Certified Robustness via Randomized Smoothing: What It Guarantees — adversarialml.dev
• Data Poisoning Attack Detection Methods That Actually Work — adversarialml.dev