What Are Known Exploited Vulnerabilities (KEVs)?
Known Exploited Vulnerabilities (KEVs) are CVE-listed vulnerabilities confirmed to be exploited in the wild. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) maintains the official KEV Catalog and mandates remediation timelines through Binding Operational Directive 22-01. Many private organizations now use this list to prioritize patching.
Although CVSS scores measure potential impact, KEVs represent active exploitation. In other words, they turn “maybe exploitable” into “being exploited,” requiring faster SLAs and automated guardrails.
KEVs vs CVEs vs EPSS
Security teams often confuse these related terms. Understanding the difference is crucial for accurate risk
| Acronym | Source | Purpose |
|---|---|---|
| CVE | NVD | Unique identifier for a disclosed vulnerability. |
| CVSS | NVD / FIRST | Measures theoretical severity (impact + exploitability). |
| EPSS | FIRST.org | Predicts probability of exploitation within 30 days. |
| KEV | CISA | Confirms real-world exploitation and sets patch deadlines. |
Together, these systems form a hierarchy of risk: CVSS shows how bad it could be, EPSS shows how likely it is, and Known Exploited Vulnerabilities show what’s actually happening.
Further reading: CVSS Score: How CVSS Scoring Works and EPSS vs CVSS: What’s the Difference?
Why KEVs Matter for Developers and CISOs
Firstly, KEVs highlight live attacker behavior. Secondly, they frequently involve third-party components, frameworks, containers, or CI/CD dependencies, that teams assume are safe. Consequently, a delayed fix can open lateral-movement paths inside your build and delivery infrastructure.
Recent examples:
- CVE-2024-1086 (Linux nf_tables): added to the KEV Catalog; exploited by ransomware groups in mid-2024.
- CVE-2023-4966 (CitrixBleed): confirmed exploitation within days of disclosure; forced emergency patch cycles worldwide.
Takeaway: KEVs are not potential threats, they’re active ones. Therefore, treat every Known Exploited Vulnerabilities as “fix-now”, unless reachability analysis proves otherwise.
How to Track and Prioritize Known Exploited Vulnerabilities
To begin with, check the official CISA Known Exploited Vulnerabilities Catalog and mark any matches inside your security scanner. Then, use this information to decide which fixes need to happen first. In addition, combine Known Exploited Vulnerabilities with EPSS scores to cut noise and focus on the weaknesses that really affect your running code.
Step-by-step workflow:
- Sync data: Pull the latest updates from the CISA list every day and combine them with your other vulnerability feeds.
- Tag results: Label each finding as “Known Exploited” when the ID matches the CISA list.
- Check reachability: See whether the vulnerable code actually runs inside your app or build pipeline.
- Assess exploitability: Use EPSS to find which other issues might soon be targeted.
- Apply deadlines:
- Internet-facing vulnerabilities: fix within 1–3 days.
- Internal ones: fix within a week.
- Code not in use: keep an eye on it and verify often.
- Automate responses: The system blocks unsafe merges, opens secure pull requests, and records exceptions to make sure teams don’t miss anything.
From Awareness to Action: Automating Fixes with Xygeni
In practice, handling all this by hand doesn’t scale. Therefore, Xygeni connects Known Exploited Vulnerabilities directly to your CI/CD workflows, turning alerts into real, guided actions.
- Smart correlation: Matches detected CVEs against the CISA list and highlights “fix-now” issues inside pull requests.
- Reachability + Exploitability: Confirms if the vulnerable code path runs and links EPSS data for precise prioritization.
- Guardrails: Stops risky merges or deployments when an exploited flaw affects sensitive files or services.
- Auto-Remediation: Opens secure PRs, checks for possible breaking changes, and runs tests before merging.
- Audit logs: Keeps clear records of what was fixed and when, supporting internal security goals.
In short, threat intelligence shows what’s being attacked, Xygeni ensures it gets fixed quickly, safely, and automatically.
Example Guardrail Policy (YAML)
guardrail:
id: "kev-protection"
description: "Block merges if known exploited vulnerability detected"
conditions:
- match: vulnerability.kev == true
- match: reachability == "reachable"
actions:
- block: merge
- notify: ["slack:#security-alerts", "jira:SEC-OPS"]
- create_pr: true
sla:
critical: 72h
high: 7dThis rule enforces no merge for active Known Exploited Vulnerabilities, notifies relevant channels, and auto-creates a fix PR, all within your CI/CD guardrails.
Mini Case: Preventing a KEV Deployment
- Week 1: A new open-source library passes SAST but includes CVE-2023-4966.
- Week 2: Xygeni’s KEV correlation detects it in the latest CISA update.
- Week 3: Guardrails halt the merge; Auto-Remediation proposes a patched version.
Outcome: The team avoided shipping a known exploited vulnerability to production and resto red pipeline flow within the same sprint.
About the Author
Written by Fátima Said, Content Marketing Manager specialized in Application Security at Xygeni Security.
Fátima creates developer-friendly, research-based content on AppSec, ASPM, and DevSecOps. She translates complex technical concepts into clear, actionable insights that connect cybersecurity innovation with business impact.
