No, not reliably. A language model answers from training data that stops at a cutoff date and from patterns it has learned, so it can miss new exploitation or state old facts with confidence. For "is this exploited now", check a live source such as the CISA KEV catalog, then hand that fact to the model.
What the model actually has
A model has a frozen snapshot of text plus whatever you put in the prompt. Exploitation status changes daily. A CVE can be quiet for months and then appear in attacks the following week. The snapshot cannot know that.
OWASP describes the underlying behaviour in its misinformation entry: the model fills gaps with statistical patterns rather than real understanding, so it can produce fabricated answers that sound correct. For exploitation status, the dangerous output is a calm, specific, wrong sentence such as "there is no known exploitation".
Which source answers the question
CISA says its Known Exploited Vulnerabilities catalog is the authoritative source of vulnerabilities that have been exploited in the wild, and that organizations should use it as an input to their vulnerability management prioritization framework. Each entry carries the CVE, vendor and product, date added, and a due date.
| Question | Poor source | Better source |
|---|---|---|
| Is it exploited in the wild? | Model memory | KEV catalog, fetched today |
| Is it present in our software? | Model guess | Your inventory or scan results |
| Can the vulnerable code run? | Model guess | Reachability evidence |
| What should we do first? | Model opinion alone | Your policy, with the facts above |
KEV is one input, not a full risk score. It says nothing about whether you run the affected product.
A safer way to use the model
- Pull the facts from systems of record: KEV status, your component inventory, scan output.
- Put those facts in the prompt, labelled with where they came from and the date fetched.
- Ask the model to explain, summarize or draft a ticket from those facts only.
- Tell it to answer "not in the data provided" when something is missing.
- Have a person confirm the final priority, and record the sources used.
This turns the model into a writer and explainer, which it does well, instead of a database, which it does not.
Warning signs in a model answer
- It states a specific date or version without a source.
- It says "not known to be exploited" without naming where it looked.
- It cites a CVE number you cannot find in any registry.
- It sounds identical whether the CVE is old or new.
Treat each of these as a reason to check the primary source before acting. See also how to ask an LLM to explain a CVE without hallucination.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the exploitability check and notice how many separate facts go into one decision.
Where Safeguard fits
Safeguard runs dependency scanning and reachability analysis against your own inventory, so the "is it in our code and can it run" half of the question comes from your environment rather than from a model's memory. You can try a free scan at https://gold.safeguard.sh/scan.
Quick check
Can I trust an LLM that has web search to answer this?
Search helps, but you still need to confirm the cited page is the primary source and that the model quoted it correctly. Open the link yourself for anything that drives a priority decision.
Is KEV enough to prioritize on its own?
No. CISA frames it as one input to a broader prioritization process. You still need to know whether the product is in your environment and exposed.
Sources
- CISA, Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
- OWASP GenAI, LLM09:2025 Misinformation: https://genai.owasp.org/llmrisk/llm092025-misinformation/
Last reviewed: 19 October 2026.
