# Understanding Known Exploited Vulnerabilities (KEV): A Practical Guide
In the evolving landscape of cybersecurity, not all vulnerabilities are created equal. While some may remain theoretical risks, others are actively exploited by malicious actors—posing immediate threats to organisations and users. To help prioritise real-world risks, the cybersecurity community uses resources like CVE (Common Vulnerabilities and Exposures) and CISA’s Known Exploited Vulnerabilities (KEV) Catalog. I have been looking at KEV and thought of writing this draft, which explores the difference between CVE and KEV and dives into how vendors and end users can act on them effectively.
## KEV vs CVE
* **CVE (Common Vulnerabilities and Exposures)** is a standardised list of publicly disclosed cybersecurity vulnerabilities, maintained by MITRE.
* **KEV** refers to entries in the **Known Exploited Vulnerabilities Catalog** (KEV), curated by **CISA**, which contains **CVE-listed vulnerabilities that are actively exploited** in the wild.
While **CVE** is comprehensive, it lacks prioritisation. That’s where **KVE** stands out: by flagging vulnerabilities that have been used in real attacks, it enables faster, risk-driven decision-making.
**Timeline Insight:**
* CVE started in **1999**.
* KEV was launched in **2021** under Binding Operational Directive (BOD) 22-01, initially for federal agencies but valuable across industries.
## KEV from a Vendor's Perspective
For software vendors, having a product listed in the KEV catalogue carries significant implications:
* **Increased Accountability**: It signals that attackers exploit a known flaw in your product.
* **Patch Responsibility**: Vendors are expected to release fixes or mitigations quickly, often under public and industry scrutiny.
* **Compliance Pressure**: U.S. federal agencies must patch or mitigate KEV vulnerabilities on strict timelines. Vendors that fail to respond may see reduced trust, legal challenges, or loss of business.
Ultimately, vendors must integrate **proactive vulnerability management** and closely monitor KEV updates to stay ahead of potential exploitation.
## KEV for End Users: From Intelligence to Action
For enterprises, KEV offers a high-value, low-noise source of threat intelligence. Rather than sifting through thousands of CVEs, organizations can focus on those **confirmed to be exploited**.
**How to Use the KEV Catalog in Practice:**
1. **Automate Feed Ingestion**:
* Pull the JSON feed from [CISA’s KEV Catalog](https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json).
* Parse it using custom scripts or integrate with security platforms (e.g., Splunk, Elastic).
2. **Cross-Reference Internally**:
* Match CVE IDs in the feed to your **asset inventory** or vulnerability scanner results.
3. **Prioritize Patching**:
* Focus remediation efforts on assets affected by KEV-listed vulnerabilities.
* Monitor `dueDate` fields to stay compliant (especially for federal agencies or contractors).
***
**Example Breakdown: CVE-2025-24054**
```json
jsonCopyEdit{
"cveID": "CVE-2025-24054",
"vendorProject": "Microsoft",
"product": "Windows",
"vulnerabilityName": "Microsoft Windows NTLM Hash Disclosure Spoofing Vulnerability",
"dateAdded": "2025-04-17",
"shortDescription": "Microsoft Windows NTLM contains an external control of file name or path vulnerability that allows an unauthorized attacker to perform spoofing over a network.",
"requiredAction": "Apply mitigations per vendor instructions, follow applicable BOD 22-01 guidance for cloud services, or discontinue use of the product if mitigations are unavailable.",
"dueDate": "2025-05-08",
"knownRansomwareCampaignUse": "Unknown",
"notes": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-24054 ; https://nvd.nist.gov/vuln/detail/CVE-2025-24054",
"cwes": ["CWE-73"]
}
```
| Field | Explanation |
| ---------------------------- | ---------------------------------------------------------- |
| `cveID` | Unique identifier for cross-referencing (`CVE-2025-24054`) |
| `vendorProject` | Vendor responsible: Microsoft |
| `product` | Affected software: Windows |
| `vulnerabilityName` | Describes the exploit (NTLM spoofing vulnerability) |
| `dateAdded` | KEV inclusion date: 2025-04-17 |
| `shortDescription` | Summary of vulnerability type and impact |
| `requiredAction` | Patch or mitigate per Microsoft; remove system if no fix |
| `dueDate` | Remediation deadline: 2025-05-08 (federal agencies) |
| `knownRansomwareCampaignUse` | No known ransomware campaigns yet |
| `notes` | Links to Microsoft and NIST advisories |
| `cwes` | CWE-73: External Control of File Name or Path |
***
## Final Thoughts: A Shared Responsibility
The KEV Catalogue represents a focused, intelligence-driven approach to vulnerability management. Whether you’re a vendor or an end user:
* **Vendors** should treat KEV listings as high-priority incidents requiring prompt fixes and clear communication.
* **Enterprises** should integrate KEV data into vulnerability management programs to improve detection, patching, and reporting.
In a world where thousands of new CVEs appear each year, KEV gives you **clarity and urgency**, helping prioritise what matters most—**the vulnerabilities that are actually being used against you**.
## References
*
*
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://jranjan.destinjidee.com/blogs/appsec/understanding-known-exploited-vulnerabilities-kev-a-practical-guide.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.