The intersection of machine learning infrastructure and software security has produced a category of risk that existing vulnerability management systems weren’t designed to handle. ML framework vulnerabilities, meaning flaws in the frameworks, serialization formats, and toolchains powering modern AI, accumulate faster than the infrastructure tracking them can process, and the gap between disclosure and defender awareness keeps widening.
What the NVD Data Actually Shows
The National Vulnerability Database remains the canonical source for CVE tracking, but the numbers expose a system under pressure. In 2025, 46,407 CVEs were published, a 16% increase over 2024, averaging roughly 127 new vulnerabilities per day. Volume that high makes triage the actual skill, and we set out a repeatable one in how to triage an ML-stack CVE. Only 28% of those received full NVD enrichment in 2025, down from 46.2% the year before, leaving a backlog of more than 54,000 CVEs without complete severity scoring or CPE mappings.
Within that volume, approximately 1,418 CVEs disclosed in 2025 targeted AI frameworks, inference engines, or AI-integrated tooling — around 3% of all new CVEs. That percentage is growing. The practical problem is that many of these entries lack the metadata — CVSS scores, CWE classifications, CPE identifiers — that security teams rely on for triage. A CVE entry with no enrichment offers little operational value to defenders who need to prioritize patching across a large ML stack. To cut through that volume, our ML Stack CVE Filter narrows the list to the frameworks and severities that actually touch your deployment.
The Distinct Character of ML Framework Vulnerabilities
What separates ML framework vulnerabilities from conventional software flaws isn’t just volume; it’s that the attack surface of ML infrastructure differs in ways the CVE taxonomy was not designed to capture.
Deserialization as a recurring vector. JFrog’s security research team documented a pattern across popular ML frameworks: PyTorch, scikit-learn, Keras (legacy HDF5), XGBoost, and H2O all use or have used pickle-based serialization for model persistence. Pickle is not a safe format — it executes arbitrary Python on load. CVE-2024-6960 demonstrated this in H2O, where unsafe Java deserialization via the Iced format let attackers achieve code execution by supplying a malicious model. CVE-2024-27132 in MLflow showed how an XSS vulnerability in recipe failure cards could escalate to full Python code execution inside JupyterLab through DOM manipulation. The JFrog researchers concluded that even “safe” model formats can be compromised if the loading library itself has unpatched bugs — meaning the format is only as secure as its implementation.
Denial of service through malformed tensors. CVE-2023-25661 in TensorFlow illustrates this category cleanly: a malformed input to the Convolution3DTranspose function triggers a check failure, crashing any model that exposes this API over a network connection. CVSS score: 6.5 (Medium). The fix requires upgrading to TensorFlow 2.11.1. The pattern recurs because rigorous input validation for arbitrary tensor shapes is architecturally difficult, and the APIs involved are common in production neural networks.
Path traversal in model archives. CVE-2023-5245 (MLeap ZipSlip) demonstrated that archiving saved models introduces traversal risk: file paths containing ../ sequences escape their intended directories during extraction, enabling arbitrary file write. The same class recurs in ML-specific loaders: CVE-2025-51480 (CVSS 8.8) is an arbitrary file write in ONNX 1.17.0, where save_external_data honours traversal sequences in a crafted external_data.location path and escapes the directory it was supposed to stay inside.
Adversarial attacks sit outside the CVE model entirely. Beyond implementation bugs, ML systems face attacks — data poisoning, model inversion, membership inference, adversarial perturbations — that produce no crash dump and no CVSSv3 score. They exploit learned model behavior, not code execution paths. The current CVE taxonomy has no entry type for “model trained on poisoned data.” For depth on that threat class, adversarialml.dev tracks adversarial ML research and attack taxonomies that NVD does not cover.
Why the Database Taxonomy Is Falling Behind
In May 2024, Senators Mark Warner and Thom Tillis introduced the Secure Artificial Intelligence Act, which would have required NIST to update the NVD to recognize that “AI systems can differ dramatically from traditional software,” and directed CISA to either modify the CVE program or create a parallel process for AI security flaws. The bill would also have established an AI Security Center at the NSA for testing infrastructure and counter-AI mitigation guidance. It expired with the 118th Congress without a vote.
The structural problem the legislation targeted is real: adversarial ML attacks don’t map to CWE entries. A model inversion attack that leaks training data leaves no exploit artifact. The entries that do map cleanly are mostly deserialization bugs, catalogued in unsafe model deserialization. An input that forces a biased classification output looks like normal traffic. These events fall outside current CVE scope by design — defenders relying on NVD-based feeds are systematically blind to a portion of the threat landscape.
NIST’s April 2026 NVD restructuring prioritizes resources for critical and high-impact CVEs, which helps triage but doesn’t resolve the AI-specific coverage gap. Practical tracking of ML-adjacent incidents — including disclosures that never receive CVE assignments — has fallen to aggregators. ai-alert.org maintains a running tracker of AI vulnerability disclosures and ML breach events that don’t fit the NVD model. One signal cuts through the enrichment problem entirely, because it is evidence rather than a score: confirmed exploitation in the wild. Which ML-stack entries have earned it, and which heavily exploited ones have not, is covered in AI CVEs in CISA KEV.
Building a Monitoring Program That Covers the Gap
Relying on NVD alone leaves blind spots for ML infrastructure. A layered approach covers more of the exposure:
GitHub Security Advisories for your specific frameworks. TensorFlow, PyTorch, Hugging Face Transformers, MLflow, and most major ML libraries publish advisories to GitHub’s security advisory database, often before NVD enrichment catches up. Subscribe to the repos you run.
Know which database you are actually querying. CVE.org publishes the CVE Records themselves, written by the assigning CNA. NVD is a separate service that adds enrichment on top of those records (CVSS, CWE, CPE) and frequently lags behind them. CISA’s Known Exploited Vulnerabilities catalog is a much shorter independent list, limited to entries with confirmed in-the-wild exploitation. CVEDetails, Tenable and similar commercial databases are downstream aggregators with their own scoring and coverage decisions. None of the four is a superset of the others, so checking your exact dependency versions against more than one surfaces entries any single feed misses.
Vendor security pages for cloud ML services. AWS SageMaker, Google Vertex AI, and Azure ML all publish security advisories on a different cadence than NVD, sometimes covering platform-layer issues that don’t get CVE assignments.
An inventory you can query when the advisory lands. A feed is only actionable if you can answer which model artifacts and which framework versions you actually run. Building that record is what AI bill of materials tools are for, and the AI SBOM minimum elements published by CISA and the G7 define the fields each entry has to carry.
Model format auditing before loading external checkpoints. Avoid pickle for untrusted model sources. Prefer safetensors or ONNX with signature verification. Treat any model downloaded from a public registry as potentially adversarial until verified — the JFrog research showed that compromised model files provide lateral movement paths into model registries and full MLOps pipelines. The per-format record, including where ONNX’s own loader CVEs sit, is in model file format security, and the full ML supply-chain attack lifecycle, from poisoned input to backdoored production model, is traced separately.
Runtime behavioral monitoring. CVEs cover code-level flaws; they don’t detect a model behaving anomalously because its weights were poisoned, or a scoring API returning systematically shifted outputs. Pairing vulnerability tracking with production monitoring closes that gap. On the framework side, our deep dives on PyTorch CVEs and hardening and TensorFlow security vulnerabilities cover what a scanner will actually flag. sentryml.com covers the observability tooling side of that problem.
There is a third failure mode worth naming, because it is invisible to every tool above: advisories with no fixed version. A scanner reports them forever and a patch cadence cannot clear them. MLflow’s cluster of unpatchable advisories is the clearest worked example on this site, and it is the case where the tracking question turns into an architecture question.
The right posture treats ML CVE tracking as necessary but not sufficient: necessary because implementation bugs in frameworks are real, patched on a schedule, and exploitable by conventional means; not sufficient because the threat model for ML systems extends into territory the CVE program was never built to address.
See also
- LangChain security vulnerabilities: CVEs and fixes
- Inference server CVEs: vLLM, Ollama, llama.cpp, Triton
- Hugging Face model supply chain risk: pickle backdoors
- trust_remote_code and the ML orchestration CVE class
- Malicious model file detection: auditing ML models
- ML model CVE tracking across your AI stack
