Safeguard
Security Guides•

How to ask an LLM about a CVE without getting made-up details

Models often get CVE details wrong from memory. Paste the advisory, restrict the answer to it, require quotes, and check the affected versions yourself.

Safeguard Security Team
3 min read

Do not ask a model to recall a CVE from memory. Paste the advisory text from the vendor or the vulnerability database, tell the model to use only that text, require a quote for each claim, and verify affected versions and fix versions against the source before acting on any of it.

Why memory is the wrong source

A model's knowledge has a training cutoff, so it may not know a recent CVE at all. It may also blend two similar advisories, or produce a believable description for an identifier it has never seen. Anthropic's hallucination guidance describes the mitigation: restrict the model to information in the documents you provide rather than its general knowledge.

For security decisions, a wrong affected version range is worse than no answer. It sends someone to patch the wrong thing or declare a system safe.

A safe way to ask

  1. Open the advisory yourself. Use the vendor or maintainer advisory first, then the database entry.
  2. Paste the relevant text into the prompt, labeled as data.
  3. Tell the model to answer only from that text.
  4. Ask for specific fields, with quotes.
  5. Let it say "not stated".
Using only the advisory below, answer in these fields.
Affected versions: (quote)
Fixed versions: (quote)
Vulnerability type: (quote)
Attack preconditions: (quote)
Workarounds: (quote)
If a field is not stated in the advisory, write "not stated". Do not use outside knowledge.

<advisory>
...
</advisory>

Anthropic describes the same pattern: ask for exact quotes first, and let the model say it cannot find relevant ones.

Verify before you act

Treat the answer as a reading aid. Check three things yourself:

  • The affected and fixed versions against the advisory text.
  • Whether your installed version, and not just your declared range, is affected. Lockfiles decide that.
  • Whether the issue is exploitable in your configuration, which depends on preconditions that may not be in the advisory.

When to be extra careful

  • Very recent advisories. The model has likely not seen them, so a pasted source is the only safe route.
  • Disputed or rejected entries. A model summarizing a withdrawn entry may present it as live.
  • Severity. Do not let the model assign its own score. Use the published score and the context you know. For scoring, see what is a CVSS severity score.

A note on scale

If you triage many findings, a pipeline can fetch the advisory automatically and fill the prompt, so the model never answers from memory. The retrieval step needs the same care as the prompt, since fetched web content can contain text meant to steer the model.

A worked example of what goes wrong

Suppose an advisory says a flaw affects versions 2.0 through 2.4.1 and is fixed in 2.4.2. A model answering from memory might say the fix landed in 2.5, because a similar library had that pattern. Your team then upgrades to 2.4.3, which is fine, but another team reads "fixed in 2.5" and blocks a safe release for a week. The pasted advisory and the "not stated" rule prevent both mistakes. Keep the advisory link in the ticket so the next person can check the same source.

Quick check

Can I trust the model's summary if it cites a CVE number?

No. A cited identifier proves nothing about the content. Compare the summary with the advisory.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.