Known Exploited Vulnerability

A known exploited vulnerability is one for which reliable evidence shows real-world attacker use. CISA maintains the Known Exploited Vulnerabilities (KEV) catalog as a public source of such findings. The catalog is a useful signal of exploitation elsewhere, not a determination that a particular deployment has been compromised.

Exploitability concerns whether and how an attack could succeed. Exploitation concerns evidence that it did. A proof of concept can inform the former without establishing the latter.

Catalog inclusion and its limits

CISA’s catalog criteria combine identification, evidence, and an available remediation action. Each criterion limits what the list contains.

  1. An assigned CVE identifier. It provides a common identifier for matching advisories to findings. An issue without one cannot yet appear as a CVE entry in the catalog.
  2. Reliable evidence of exploitation in the wild. A theoretical attack or published demonstration alone does not establish real-world malicious use.
  3. A clear remediation action. This can include an update, mitigation, or discontinuing use as directed for the entry. Actionability does not mean that a vendor patch always exists.

Scanning activity, research, or publication of exploit code does not by itself show that a vulnerability was successfully exploited against a victim. Conversely, a public proof of concept is not required for exploitation to have occurred. Assess the evidence behind a report instead of treating code availability as confirmation.

How to use it, and how not to

Use the catalog with severity, local exposure, business impact, and other threat evidence. FIRST’s EPSS FAQ distinguishes this historical signal from a forecast: EPSS estimates the chance of observed exploitation during the next thirty days. Neither input supplies a complete local risk assessment.

A listed vulnerability warrants prompt assessment of affected instances, including internal and indirect attack paths. Internal-only reachability does not make an exploited flaw routine, and unknown exposure calls for investigation rather than a lower priority. An unlisted vulnerability may also require urgent action. CISA’s binding operational directives apply to covered federal civilian executive branch (FCEB) agencies; other organizations must identify their own applicable requirements. Record a justified deadline and escalate changed evidence rather than waiting for complete certainty before assigning an owner.

Absence means only that a vulnerability is not in this catalog. Evidence may not yet have been detected, reported, reviewed, or accepted for inclusion, and other criteria can delay entry. FIRST’s EPSS FAQ gives an approximate estimate of 0.5% of published CVEs appearing in KEV; that changing catalog proportion is not the probability that an unlisted finding is safe.

Limits to account for in your process

  • Observation bias. The list reflects what defenders detected and reported. Quiet attacks or poorly instrumented environments can escape observation.
  • Product coverage. Product representation depends on exploitation, reporting, and eligibility; do not treat the catalog as uniform surveillance of all software.
  • Timing. Entry follows evidence, which follows exploitation. The interval between the two is exposure you cannot schedule away, which is the argument for patch cadence as well as for emergency response.
  • No instance context. The catalog knows nothing about your deployment. Reachability, whether the affected feature is enabled, and what the host holds are yours to determine, and they are what turn a listed identifier into a ranked finding.

Keep this column separate from severity and from predicted probability. Severity is what CVSS scores; probability of near-term exploitation is what a prediction model estimates; observed exploitation is a fact about the past. Combining them without preserving the inputs makes a ranking harder to explain. Where a fix is deferred despite the evidence, that decision belongs in a recorded vulnerability exception rather than in a spreadsheet comment. The underlying distinction between a vulnerability and an attack is covered in threat and vulnerability.

How this signal fits with exposure, business impact, patch cadence, and ownership is set out in Twelve Thousand Findings.

References


Discover more from Insightful Data Lab

Subscribe to get the latest posts sent to your email.

Similar Posts

Questions, corrections, or additional insights?

This site uses Akismet to reduce spam. Learn how your comment data is processed.