Notifications
Clear all
Topic starter
02/08/2026 11:41 am
TL;DR: Eight of 122 CISA KEV additions from October 2025 to March 2026 were already exploited in the wild before listing, with a median lead time of 5.5 days and a range from 1 to 31 days, according to Nucleus. Waiting for KEV, EPSS, or public consensus now leaves teams behind attacker timelines, not ahead of them.
NHIMG editorial — based on content published by Nucleus: The Exploitability Intelligence Gap and pre-KEV exploitation patterns
By the numbers:
- Nucleus reviewed 122 new vulnerabilities added to CISA KEV between October 2025 and March 2026.
- The review found 8 of those 122 vulnerabilities were already exploited in the wild before KEV listing.
- Mandiant’s M-Trends 2024 report found average time-to-exploit dropped by approximately 92% from 2018-19 to 2023.
Questions worth separating out
Q: How should security teams prioritise vulnerabilities that appear in KEV lists?
A: Security teams should prioritise vulnerabilities by evidence of active exploitation, reachability in the running environment, and privilege impact.
Q: Why do CISA KEV and EPSS still leave exposure gaps?
A: Because both are signals, not guarantees of when attackers will act.
Q: What breaks when teams wait for confirmed exploitation before patching?
A: The response window collapses.
Practitioner guidance
- Add pre-KEV escalation criteria to vulnerability triage Define a trigger set that includes public proof-of-concept release, commercial threat intelligence, ransomware mention, and exploit chatter, then route those cases for same-day review even when CISA KEV is still empty.
- Correlate exploit signals in one prioritisation workflow Unify EPSS, PoC monitoring, vendor advisories, and internal asset criticality so analysts are not stitching evidence together manually across disconnected feeds.
- Map vulnerable services to identity blast radius For every externally reachable application or developer tool, document whether a compromise could expose service accounts, API keys, certificates, or admin sessions.
What's in the full report
Nucleus's full analysis covers the operational detail this post intentionally leaves for the source:
- A complete breakdown of all 122 KEV additions reviewed during the six-month window.
- Per-CVE pre-KEV signal analysis showing how public PoCs, EPSS, and threat intelligence lined up before confirmation.
- The Nucleus Threat Rating approach and how it is used inside exposure management workflows.
- The full case-by-case evidence for Gogs, Notepad++, FileZen, and Chromium.
👉 Read Nucleus's analysis of the exploitability intelligence gap before CISA KEV →
Pre-KEV exploitation: is your vulnerability prioritisation too slow?
Explore further
02/08/2026 12:53 pm
Pre-KEV exploitability is a governance gap, not just a timing problem. The market often treats CISA KEV as the point at which risk becomes real, but this article shows that exploitation can be active long before formal listing. That means the issue is less about missing a signal and more about over-trusting the signal that is easiest to defend internally. Practitioners need decision paths that can escalate on layered evidence, not only on confirmed catalog status.
A question worth separating out:
Q: Who is accountable when pre-KEV exploitation is missed?
A: Accountability usually sits across vulnerability management, security operations, and the asset owner, because the failure is often a process gap rather than a single missed alert. Organisations should assign a clear owner for pre-KEV escalation decisions and define when exploitability evidence is enough to trigger compensating controls.
👉 Read our full editorial: Pre-KEV exploitation is closing the vulnerability response window
