About ML CVEs

CVEs in ML libraries, frameworks, and the AI/ML supply chain.

ML CVEs tracks vulnerabilities in machine-learning infrastructure: PyTorch, TensorFlow, ONNX, vLLM, llama.cpp, transformers, LangChain, LlamaIndex, model registries and the wider model supply chain, including pickle-backdoor and malicious-model-file risk.

Each entry is dated and sourced to NVD, a vendor advisory, or the upstream commit. It is written for the person who has to decide whether an advisory affects their stack this week.

What is covered here

• AI Security
• Defense
• Guides
• ML Security
• Supply Chain
• Tools
• Vulnerability Disclosure
• Vulnerability Tracking

18 articles are published so far. New articles are announced on the RSS feed; there is no fixed publishing schedule and this site does not promise one.

How these articles are produced

Articles are researched from primary sources: vendor and project documentation, published standards and specifications, release notes, advisories, and measurements published by the people who took them. Drafts are produced with AI assistance and then edited against those same sources before anything is published. Where a figure comes from a datasheet or a third-party measurement, the article names the source and links to it so you can check the original rather than take this site's summary of it.

Everything here is published under the ML CVEs Editorial byline. That is an editorial desk, not a person, and no article on this site claims hands-on lab testing, benchmarking, or first-hand measurement. Nothing here should be read as a report of something this site physically tested.

How CVE entries are verified

A CVE tracker is only worth reading if its identifiers are real and attached to the right product. Every CVE ID cited on this site, and every ID in the ML stack CVE filter, is checked against the NVD API before it is published: the identifier must exist, it must not have been withdrawn by its numbering authority, and the NVD record must describe the product the entry claims.

Scores need one more distinction, because a CVE usually carries two. The CNA that assigned the ID publishes its own CVSS vector, and NVD analysts often publish a different one for the same entry. Where NVD has done its own CVSS v3.1 analysis, that is the number shown here; where it has not, the CNA's score is shown instead. The gap is not cosmetic: NVD scores the five 2024 llama.cpp GGUF overflows at 9.8, while Cisco Talos, the CNA, scored them 8.8, and NVD scores several NVIDIA Triton entries a full point above NVIDIA's own bulletin. If a scanner disagrees with this table, the scoring source is the first thing to check.

The 19 August 2026 pass applied these checks to the whole filter dataset. It removed 45 entries - 9 whose IDs are not published in NVD, 3 withdrawn by their CNA, and 33 whose NVD record describes an unrelated product - corrected 44 CVSS base scores, re-attributed 6 entries to the right package, and added 33 entries, 27 of them covering the inference-serving runtimes. Affected and fixed version ranges are a weaker signal: they come from the linked advisory and are not independently re-derived, so the filter says so on the page and links the NVD record for every entry so you can check the original.

Corrections

Getting it right matters more than getting it first. If something on this site is wrong, out of date, or missing the source it should cite, email hello@mlcves.com with the page and the specific claim. Substantive corrections are made on the page itself rather than quietly dropped.

How this site is funded

This site currently runs no affiliate links, no sponsored content, no paid placement, and no display advertising. Nothing on it earns a commission. If that changes, this page and the disclosure page will say so before any such link appears.

The full position is on the disclosure page. Read it before acting on anything here that reads like a buying recommendation.

Related sites

ML CVEs is run alongside a small number of other single-topic sites:

• Adversarial ML - Working adversarial ML — exploits, defenses, and the gap between.
• AI Attacks - Practitioner-grade AI red team techniques and tooling.
• AI Sec - Offensive AI security — prompt injection, jailbreaks, agent exploitation, red team writeups.
• JailbreakDB - An indexed catalog of working LLM jailbreak techniques.
• Jailbreaks FYI - Working LLM jailbreak techniques, sourced and dated.

Contact

Email: hello@mlcves.com
Site: mlcves.com
Privacy: privacy policy · terms of use