Your vulnerability scanner reports a CVE with CVSS 5.1. Moderate risk, your team decides. Patch it next quarter along with the other maintenance fixes.
But then your incident response team pages you at 2 AM—attackers are exploiting that exact CVE right now against your systems.
This scenario plays out regularly at organizations that don't monitor CISA's Known Exploited Vulnerabilities (KEV) catalog. While your team is reading CVSS scores, threat actors are actively weaponizing specific vulnerabilities. CISA KEV separates theoretical risk from present danger.
TL;DR: CISA KEV is a catalog of CVEs that have been confirmed actively exploited by real threat actors — not theoretical. A CVSS 4.0 on KEV is more urgent than a CVSS 9.8 that nobody's exploiting. Federal agencies must patch KEV entries within 3–15 days; private-sector teams should treat them as emergency patches (24–48 hours). The catalog has 1,200+ entries and grows daily. This guide explains how entries get added, how KEV works alongside EPSS, and how to build a KEV-aware response workflow.
What We'll Cover
- What CISA KEV is and who runs it
- The vulnerability signal confidence pyramid
- How the KEV catalog has grown since 2021
- Anatomy of a KEV entry
- How CISA decides what to add
- Timeline: from CVE disclosure to KEV entry
- Real-world KEV examples (Log4j, Confluence, VMware)
- KEV vs EPSS: how they work together
- Building a KEV-aware incident response process
- When KEV hits your ecosystem (npm, Python, Java, Go, .NET, Rust)
What Is CISA KEV?
CISA (Cybersecurity and Infrastructure Security Agency), the cybersecurity arm of the U.S. Department of Homeland Security, maintains the Known Exploited Vulnerabilities catalog—a curated list of vulnerabilities actively exploited by real threat actors in the wild.
Each KEV entry includes:
- CVE ID
- Date CISA added the vulnerability to the catalog
- Required action deadline (typically 3–15 days for federal agencies)
- Vendor advisory links
- Evidence of exploitation (public PoC, malware inclusion, attack reports)
The critical distinction: KEV doesn't mean the vulnerability exists. It means someone is exploiting it right now.
Your patch priority flips from "we should fix this eventually" to "we must fix this before tomorrow's security briefing."
The Vulnerability Signal Confidence Pyramid
Think of vulnerability intelligence as a pyramid of confidence, from theoretical to confirmed:
╱╲
╱ ╲
╱ 🔴 ╲ CISA KEV
╱ KEV ╲ "Confirmed active exploitation"
╱────────╲ Confidence: Verified evidence
╱ ╲ Action: Patch in 24 hours
╱ 🟠 EPSS ╲
╱ > 0.7 ╲ EPSS (High)
╱─────────────────╲ "Likely to be exploited soon"
╱ ╲ Confidence: ML prediction
╱ 🟡 EPSS 0.3–0.7 ╲ Action: Patch this week
╱───────────────────────╲
╱ ╲
╱ 🟢 CVSS Score Only ╲ CVSS
╱─────────────────────────────╲ "Could be bad if exploited"
╱ ╲ Confidence: Theoretical
╱ (Most scanners stop here) ╲ Action: Normal patch cycle
╱───────────────────────────────────╲
Most scanners — including npm audit, pip-audit, and basic GitHub Dependabot alerts — only see the bottom layer. They tell you "this could be bad" but not "this is being exploited right now." KEV is the apex of the pyramid: the highest-confidence signal you can get.
A CVSS 4.0 vulnerability at the top of the pyramid (KEV) demands more urgent action than a CVSS 9.8 at the bottom (CVSS-only). Yet most organizations prioritize the 9.8 first because that's all their scanner shows them.
KEV Catalog Growth Since 2021
The KEV catalog has grown steadily since CISA launched it in November 2021:
KEV Entries by Year (approximate cumulative)
─────────────────────────────────────────────
2021 (Nov-Dec) ██ ~300 initial entries
2022 █████████████ ~650
2023 ████████████████████ ~900
2024 █████████████████████████ ~1,100
2025 ████████████████████████████ ~1,250+
2026 (ongoing) ██████████████████████████▌ growing (check cisa.gov/kev for current total)
─────────────────────────────────────────────
This growth reflects two trends: threat actors are weaponizing vulnerabilities faster, and CISA's intelligence collection is improving. The catalog isn't exhaustive — plenty of vulnerabilities are exploited without appearing on KEV — but it's the most authoritative public source for confirmed active exploitation.
Anatomy of a CISA KEV Entry
Each KEV catalog entry contains essential intelligence:
CVE-2023-46805 (fictional example):
Vulnerability: Remote Code Execution in Acme Library v2.1
CVSS Score: 7.8
Date Added to KEV Catalog: 2023-10-15
Required Action Date: 2023-10-28 (for federal agencies)
Evidence of Exploitation: Public PoC code available, incorporated in malware
Affected Versions: Acme Library 2.0–2.4
Patch Available: Yes (Acme Library 2.5+)
References: CISA Advisory, Vendor Patch, Public PoC
The key detail: Date Added to KEV Catalog isn't necessarily when the vulnerability was discovered—it's when CISA confirmed active exploitation. There's often a lag of weeks between CVE disclosure and KEV inclusion. This is why monitoring both is critical.
Once a vulnerability is on CISA KEV, federal agencies are legally required to patch within the deadline (usually 3–15 days depending on severity). Private sector organizations aren't mandated by law, but they should treat KEV entries as emergency patches.
How Does CISA Know What's Being Actively Exploited?
CISA adds vulnerabilities to the KEV catalog based on multiple intelligence streams:
U.S. Government agency reports:
- CISA incident response teams
- NSA cybersecurity advisories
- Department of Defense security bulletins
Information Sharing and Analysis Centers (ISACs):
- Financial ISAC (attacks on banks)
- Healthcare ISAC (attacks on hospitals)
- Energy ISAC (attacks on power grids)
- Sector-specific threat intelligence
Public exploit evidence:
- Functional proof-of-concept code on GitHub
- Metasploit modules
- Public security researcher disclosures
Malware and attack analysis:
- Commercial threat intelligence feeds
- Automated detection of malware incorporating the flaw
- Attack campaign analysis from security vendors
Vulnerability databases:
- Exploit-DB
- Google Project Zero
- Security vendor advisories
CISA doesn't wait for perfect certainty. If there's credible evidence a vulnerability is being exploited, it gets added to KEV. The bar is "actively exploited," not "maybe someday exploited." For the full details on how the catalog is maintained and published, see CISA's Binding Operational Directive 22-01.
Timeline: From Disclosure to KEV
Here's the timeline of how a critical vulnerability moves from disclosure to KEV status:
Day 0: CVE disclosed to NVD
↓
Day 1-5: Security researchers publish analysis
↓ Threat intelligence teams detect references in attack forums
↓
Day 2-7: Public proof-of-concept published
↓ Threat actors begin testing the flaw
↓
Day 5-15: Malware incorporates the exploit
↓ Mass exploitation detected in the wild
↓
Day 10-21: CISA receives evidence and verifies
↓
Day 15-30: Vulnerability added to CISA KEV catalog
↓ EMERGENCY - Patch immediately
The gap between disclosure and KEV entry varies wildly. Some vulnerabilities (especially zero-days) hit KEV within days. Others take weeks. The pattern is consistent though: by the time a vulnerability is on KEV, threat actors are already exploiting it at scale.
Real-World KEV Examples
Real vulnerabilities that ended up on CISA KEV:
| CVE | Vulnerability | CVSS | Days to KEV | Impact |
|---|---|---|---|---|
| CVE-2021-44228 | Apache Log4j RCE | 10.0 | 1 day | Weaponized within hours; affected millions of apps |
| CVE-2021-3129 | Laravel Framework RCE | 9.8 | 10 days | PHP developers targeted at scale |
| CVE-2020-1938 | Apache Tomcat AJP Ghostcat | 9.8 | 6 days | Internal data exposed; mass scanning detected |
| CVE-2022-26134 | Atlassian Confluence RCE | 10.0 | 7 days | Confluence instances breached; data theft campaigns |
| CVE-2021-21985 | vCenter Server RCE | 9.8 | 8 days | VMware infrastructure compromised in targeted attacks |
Notice: Time to KEV ranges from 1-10 days. By the time these entries appeared on the CISA catalog, exploitation was already happening at large scale. Teams that were still patching only "High CVSS" items were already behind.
KEV vs EPSS: Complementary Signals
CISA KEV and EPSS serve different purposes:
CISA KEV: Binary "Yes, this is being exploited RIGHT NOW"
- Evidence-based (not predictive)
- Highest confidence signal
- Requires immediate action (24-48 hours)
EPSS: Probabilistic "This will likely be exploited in the next 30 days"
- Predictive (based on machine learning)
- Useful for forward-looking prioritization
- Allows for more measured response (1 week)
Together:
- KEV + High EPSS = Actively exploited AND spreading. Crisis mode.
- KEV + Low EPSS = Actively exploited but contained. Still urgent but possibly more contained.
- No KEV + High EPSS = Not yet weaponized but will be soon. Proactive defense window.
- No KEV + Low EPSS = Standard vulnerability. Normal patch cadence.
GeekWala integrates both signals so you don't have to manually cross-reference CISA KEV and EPSS threat intelligence. When you scan your dependencies, vulnerabilities on KEV are flagged immediately.
How CISA Updates the KEV Catalog
CISA publishes the complete KEV catalog as a JSON feed (publicly available) and updates it continuously. The catalog is governed by Binding Operational Directive (BOD) 22-01, which mandates federal agencies patch KEV entries within specified deadlines.
The workflow:
- CISA receives evidence of active exploitation
- Analysts verify the evidence (PoC code, malware samples, attack reports)
- Vulnerability is added to KEV with an "added" date
- A "required action date" is set (federal agencies must patch by this date)
- The catalog is updated in near-real-time
You should check the KEV catalog:
- Daily if you operate critical infrastructure or handle sensitive data
- Weekly at minimum for any production system
- Immediately after a vulnerability disclosure in your ecosystem
Building a KEV-Aware Incident Response Process
When a new KEV entry drops for a dependency you use, treat it as a mini-incident. Here's the runbook:
┌─ KEV ALERT RECEIVED ─────────────────────────────┐
│ │
│ 1. ASSESS (first 30 minutes) │
│ • Do we use the affected package? │
│ • Which environments are affected? │
│ • Is the vulnerable code path reachable? │
│ │
│ 2. CONTAIN (first 2 hours) │
│ • Apply WAF rules if available │
│ • Isolate affected services if critical │
│ • Notify on-call team │
│ │
│ 3. REMEDIATE (within 24 hours) │
│ • Bump dependency version │
│ • Run test suite against patched version │
│ • Deploy to staging → verify → production │
│ │
│ 4. VERIFY (within 48 hours) │
│ • Rescan with GeekWala to confirm resolution │
│ • Check for additional transitive exposure │
│ • Document the incident for post-mortem │
│ │
└───────────────────────────────────────────────────┘
KEV demands incident-level urgency, not just prioritized patching. KEV entries aren't "patch soon" — they're "attackers are using this right now." For the EPSS-based triage workflow (which handles everything below KEV severity), see our EPSS deep dive.
When KEV Hits Your Ecosystem
A KEV entry affects different ecosystems differently. Here's how to respond based on your stack:
- npm/Node.js: KEV entries in transitive dependencies are common —
npm auditwon't flag KEV status, so layer EPSS + KEV on top of npm audit - Python/PyPI: Python's fragmented advisory databases mean KEV entries may not appear in
pip-auditimmediately — Python dependency scanning workflow - Java/Maven: Log4Shell showed how a single KEV entry can cascade through 200+ transitive dependencies — Java vulnerability scanning and prioritization
- Go: Stdlib KEV entries (e.g.,
net/http) affect every Go service — Go module security and govulncheck - .NET/NuGet: Enterprise .NET teams need to trace KEV entries through
Directory.Packages.propsand transitive chains — NuGet vulnerability scanning guide - Rust/crates.io: KEV entries in
unsafecrates (likeringormio) are especially dangerous — Rust dependency security guide
For EPSS-based triage of vulnerabilities that aren't yet on KEV, see our EPSS deep dive.
Frequently Asked Questions
How can I get notified when a KEV entry is added for my dependencies?
Scan your dependencies with GeekWala to get real-time notifications when vulnerabilities are added to CISA KEV. You can also subscribe to CISA's mailing list or use RSS feeds to the KEV JSON catalog directly.
What if a vulnerability is on KEV but we've already patched?
You're good. Your scan results will still show the KEV entry for historical context, but if your versions are updated beyond the affected range, you're not at risk.
Does CISA KEV cover all vulnerability types?
CISA KEV focuses on vulnerabilities with clear evidence of active exploitation. It's not exhaustive (many vulnerabilities are exploited but not on KEV), but everything on KEV is high-priority.
Can I use KEV status for compliance?
Yes. Many compliance frameworks (NIST Cybersecurity Framework, CISA Cybersecurity Performance Goals) specifically call out prioritizing KEV entries. Combine this with EPSS scores for a comprehensive risk-based approach. If a vulnerability is on CISA KEV, it's defensible to treat it as emergency priority even if your compliance framework doesn't explicitly require 24-hour response.
What's the difference between KEV and "trending" vulnerabilities?
KEV is evidence-based (CISA verified active exploitation). Trending vulnerabilities are gaining mentions in threat intelligence but may not be actively exploited yet. KEV is higher confidence signal.
How do I tell how fresh a KEV entry is?
Each KEV entry includes an "added" date and a "required action date" (usually 15 days after addition for federal agencies). A recently added entry means exploitation was just confirmed — the threat is active and escalating. An older entry means the threat is established but may have known mitigations.
What if a KEV entry is older than my scan date?
The vulnerability was already being exploited before your scan. If your system is vulnerable, you should've patched it days or weeks ago. This is why continuous or frequent scanning is critical—you don't want to discover you're vulnerable to actively-weaponized flaws.
Find out if any of your dependencies are on CISA KEV right now.
Check your dependencies against the KEV catalog → — every finding is cross-referenced against the live CISA KEV list. If you're running something that's actively exploited, you'll know in under a minute. No account needed.
