To verify an "exploited in the wild" claim, find who made the observation, what they saw, and whether an independent source agrees. Check the vendor advisory and the CISA Known Exploited Vulnerabilities catalog. A claim backed by two of those sources deserves fast action. A single unnamed source deserves a quick check and a note.
Who observed it
Strong claims name the party that saw the activity: the vendor's own response team, a security firm with telemetry, a government agency, or the victim. Weak claims say "reports suggest" or "attackers are said to be".
What was seen
Look for specifics: which vulnerability, which product versions, what the attackers did after exploiting it. Evidence of attempted scanning is not the same as successful compromise, and both differ from a proof of concept existing on a public site.
The CVSS specification treats these as threat information that can adjust severity, for example whether proof of concept code exists or the flaw is being actively exploited. They are different levels, so keep them apart in your notes.
Check the catalog
CISA describes its Known Exploited Vulnerabilities catalog as the authoritative source of vulnerabilities that have been exploited in the wild, and asks organisations to use it as an input to prioritisation. Entries carry fields such as date added, due date, ransomware use and whether forensic triage is required. If a flaw is listed, that is strong confirmation. If it is not listed yet, that is not proof of safety, since entries are added over time.
Check the vendor
Vendors often add a line to the advisory when they know of exploitation. Compare dates. If the advisory was updated after the first version, read the change.
Weigh it against a forecast
EPSS answers a different question: the FIRST FAQ says it estimates the probability of exploitation in the next 30 days. A confirmed exploitation report makes the forecast less important for that item.
Click through it at your own pace, or open it full screen.
What changes when it is confirmed
Move from "plan the patch" to "patch or mitigate now, and look backward". If the vulnerable service was exposed, check logs from before the patch date for signs it was used against you. The KEV entries mention forensic triage for a reason: patching does not remove an intruder who already got in.
What to write down
Source of the claim, date you verified it, whether it is in the catalog, your exposure, your decision.
Quick check
Is a public proof of concept the same as exploitation?
No. A proof of concept shows how, and makes attacks easier, but exploitation means attacks were observed.
If it is not in the catalog, can I ignore it?
No. Use your other checks. The catalog grows over time and reflects what has been added, not everything that happens.
Sources
- CISA, Known Exploited Vulnerabilities Catalog
- FIRST, CVSS specification document
- FIRST, EPSS frequently asked questions
Last reviewed: 19 October 2026.
