CISA’s Known Exploited Vulnerabilities catalog identifies vulnerabilities with evidence of exploitation. Inclusion is an important threat signal, but local applicability and exposure still determine what the organization needs to do.
What it is
The KEV catalog is a curated record of vulnerabilities with evidence of exploitation. It is not a prediction system and not a list of every possible vulnerability. Its value is the affirmative signal that exploitation is known, which should remain distinct from a severity score or probability estimate.
A catalog entry still needs to be connected to the actual deployment. If the product or affected condition is absent, the entry does not create a local vulnerability. If applicability is confirmed, known exploitation can materially change the urgency of review and response.
How it works
CISA publishes entries with vulnerability identifiers and supporting information, including relevant actions and dates. Review the entry together with trusted vendor guidance to understand affected conditions and the appropriate response. Preserve the catalog and advisory context used in the decision.
Dates have specific meanings
The date an item is added to the catalog is not necessarily when exploitation began, when the vulnerability was discovered or when your asset became exposed. A remediation due date also has a particular policy context. Keep these distinctions clear in timelines and management reporting.
Evidence and forecast are complementary
Known exploitation is an observation-based signal. EPSS is a forecast. A low model estimate does not invalidate the existence of known exploitation. Likewise, a high severity score without catalog membership does not establish that exploitation has occurred. Record the signals separately.
Required action can differ by product
A response may involve applying an update, following vendor mitigation instructions or taking other appropriate action when a fix is unavailable. Do not assume that changing a displayed version string is sufficient. The vendor’s affected conditions and remediation guidance should drive verification.
Technical references: CISA · Known Exploited Vulnerabilities Catalog · CVE Program · Record User Guide
How attackers use it
Attackers may continue using vulnerabilities after public disclosure and after fixes exist, particularly where affected services remain reachable. The existence of a remediation path does not mean it has been applied everywhere. This is why confirmed applicability and current exposure remain central to prioritization.
Defenders should also review whether the relevant service may have been affected before the fix. Patching removes or changes a weakness; it does not establish that earlier exploitation did not occur. Incident investigation is warranted when the evidence indicates suspicious activity or consequential exposure requiring review.
Warning signs
Promptly review confirmed applicable entries on public-facing or privileged services. Investigate findings that remain unresolved because ownership is unclear, applicability is based on stale evidence or a temporary mitigation has never been validated.
Avoid misleading conclusions
Do not label a local asset “exploited” solely because its matched CVE appears in KEV. Use wording that distinguishes known exploitation of the vulnerability from confirmed activity on the asset. Conversely, do not label a nonlisted vulnerability “not exploited” without appropriate evidence.
Business impact
Known exploitation can make delay more consequential, particularly for accessible services with important privileges or data. A clear process helps teams move from an intelligence update to an accountable decision without losing time on ambiguous asset matching.
Misclassification also has a cost. Treating every catalog match as a confirmed breach can trigger unnecessary incident escalation, while ignoring applicability-confirmed entries can leave important paths open. Evidence-based wording supports appropriate action at both technical and leadership levels.
Prevention and remediation
Monitor relevant catalog and vendor updates, maintain asset and component records and assign owners for applicability review. Document the selected action and verify it against the affected condition. Review temporary mitigations and unresolved exceptions as intelligence or exposure changes.
Verification record
- The asset and deployed component are identified reliably. - The affected conditions and catalog reference are recorded. - The chosen action follows applicable vendor guidance. - The resulting configuration or component state is verified. - Any separate evidence of local exploitation is investigated. - Remaining exceptions have an owner and a review trigger.
How Ariema detects or handles it
Ariema’s possible CVE context and external service evidence can help connect a relevant vulnerability to an asset requiring review. Timestamped observations can support the exposure timeline and later verification of a changed public condition.
Catalog membership should retain its authoritative source and should not be presented as Ariema having detected a local exploit. Applicability and incident evidence need their own assessment. The product’s follow-up and retest workflow can record the action and its verified result.
Common questions
Does KEV membership prove our organization was compromised?
No. It establishes known exploitation of the vulnerability, not a local incident. Assess your deployment and relevant activity evidence separately.
Does absence from KEV mean no exploitation exists?
No. Catalog absence is not proof that a vulnerability is unexploited or harmless. Consider other reliable intelligence and local evidence.
Do catalog due dates apply identically to every organization?
No. Applicability of particular federal requirements depends on the organization and governing obligations. Other organizations can use the catalog as prioritization evidence without treating every displayed date as their own legal deadline.
Sources & further reading
Primary technical references for this guide. Scenarios are illustrative; they are not customer observations.
CISA · Known Exploited Vulnerabilities CatalogCVE Program · Record User GuideNIST · Enterprise patch management planning