RESEARCH · A reference synthesis of the public vulnerability-scoring systems (CVSS, EPSS, CISA KEV), grounded in our own computation on 2025 exploitation data. No new vulnerabilities were disclosed in this work.

Vulnerability prioritization is the practice of deciding which vulnerabilities to fix first when you cannot fix them all at once. In 2026 the honest answer is that no single score does it well: CVSS measures how bad a flaw could be, EPSS estimates how likely it is to be exploited, and CISA's KEV catalog records what is being exploited right now. CVSS alone is the most common (and most misleading) way to rank a patch queue, because it says nothing about whether anyone is actually attacking the bug. The reliable method combines all three signals and weights hard evidence of a public exploit above any score. This page is Nexus Void's reference on how those signals differ, where each one fails, and how to build a prioritization model that reflects real-world risk instead of a number in a spreadsheet.

We ground every claim here in primary data, using NVD for CVSS, FIRST.org for EPSS, and CISA for KEV, plus our own analysis of 2025's actively exploited vulnerabilities. That analysis found that 67% of 2025's actively-exploited vulnerabilities would have been missed by a once-a-year pentest, the median gap between disclosure and exploitation was just 26 days, and 20% were exploited on or before the day they were disclosed. Those three numbers are why prioritization, not perfection, is the job.

Why can't you just patch everything?

Because the math doesn't allow it. Tens of thousands of CVEs are published every year, enterprise scanners routinely surface hundreds of thousands of findings across a fleet, and remediation competes with uptime, change windows, and regression testing. Prioritization exists because the realistic constraint is never "fix all," it is "fix the right ones first, this week." The question is which signal you trust to define "right."

The default answer for two decades has been CVSS severity: patch the 9s and 10s, get to the rest later. That feels responsible and is quietly wrong, because severity and urgency are different questions. A flaw can be catastrophic in theory and never attacked in practice, while a "medium" flaw gets mass-exploited within days. Ranking by severity alone systematically spends your scarce remediation capacity in the wrong place.

What is CVSS, and what does CVSS miss?

CVSS (the Common Vulnerability Scoring System, maintained by FIRST) is a 0–10 score describing the intrinsic technical severity of a vulnerability: how it's exploited (attack vector, complexity, privileges required) and what it costs you (impact to confidentiality, integrity, availability). It is the number in every NVD entry and the backbone of most patch SLAs.

What CVSS misses is threat context. The base score is static and deliberately excludes whether an exploit exists, whether anyone is using it, how widely the product is deployed, or how exposed your instance is. Two consequences follow, and both are common:

• High-CVSS flaws that are not urgent. A CVSS 9.9 in a product no attacker is targeting can sit safely for weeks while you handle something scored lower but actively exploited.

• Low-CVSS flaws that are on fire. A "medium" score can hide a bug that is trivial to weaponize on a device that controls your whole environment.

The clearest 2026 example is Cisco FMC CVE-2026-20316: a static-credentials flaw scored just CVSS 5.3 (Medium) that was nonetheless exploited as a zero-day and added to CISA KEV, because low-privilege access on a device that manages an organization's firewalls is a launch pad, not a footnote. A pure-CVSS queue buries it under dozens of scarier-looking 9.8s. That is the failure mode in one CVE.

What is EPSS, and where does EPSS fall short?

EPSS (the Exploit Prediction Scoring System, also from FIRST) answers the question CVSS ignores: how likely is this vulnerability to be exploited in the next 30 days? It outputs a probability (0–1) and a percentile, updated daily from real-world signals like exploit publication, scanning activity, and threat intelligence. Used well, EPSS is a powerful re-ranker: it pushes the genuinely dangerous bugs up and lets you defer the theoretical ones.

Where EPSS falls short is at the edges, and security teams get burned there. EPSS is a statistical prediction trained on historical exploitation patterns, so it systematically undersells certain categories:

• Fresh kernel and local-privilege-escalation bugs. These often show low EPSS and low percentiles even when a reliable public exploit already exists, because the model hasn't yet seen the exploitation signal it keys on. GhostLock CVE-2026-43499 is the textbook case: CVSS 7.8, EPSS around the 50th percentile, and not in KEV, yet a public, ~97%-reliable root exploit exists. All three headline signals understate it. Ubuntu snap-confine CVE-2026-8933 tells the same story with an EPSS near the 12th percentile despite being a clean local-root primitive.

• The inverse is also useful. Windmill CVE-2026-29059 scores only CVSS 6.9 (Medium) but sits around the 84th EPSS percentile and was actively exploited. Here EPSS correctly flags what CVSS dismisses.

The lesson: EPSS is a strong second opinion, but for kernel, container-escape, and local-privesc bugs, weight "a public exploit exists" above the EPSS number.

What is the CISA KEV catalog, and what are its limits?

The CISA Known Exploited Vulnerabilities (KEV) catalog is a list of CVEs with confirmed, reliable evidence of active exploitation in the wild. It is the highest-confidence signal of the three: KEV doesn't predict, it reports. If a CVE is in KEV, exploitation is not hypothetical, and for U.S. federal agencies KEV entries carry binding remediation deadlines. Any prioritization model in 2026 should treat "in KEV" as an automatic top-of-queue.

KEV's limit is that it is a floor, not a ceiling, and it lags. It only lists what has been confirmed exploited, so a brand-new bug with a public proof-of-concept but no observed campaign yet won't be in KEV even though it is dangerous today. GhostLock, above, is not in KEV despite a working exploit. KEV tells you what's already burning; it can't tell you what's about to catch. Treat its absence as "no confirmation yet," never as "safe."

CVSS vs EPSS vs KEV: how the three signals compare

Each signal answers a different question, and their disagreements are where prioritization actually happens.

The real-world cases show every combination:

Notice that only the Oracle EBS row is unambiguous. Every other row requires judgment, and a single-signal model gets at least one of them wrong.

How should you actually prioritize patches in 2026?

Lead with evidence, then likelihood, then severity, and always factor your own exposure. A workable ordering that any team can apply:

1. In CISA KEV → patch first. Confirmed exploitation, no debate.

2. Public exploit / PoC exists → treat as KEV-equivalent, even if EPSS is low and it's not yet in KEV. This is the rule that catches kernel and local-privesc bugs the scores miss.

3. High EPSS (roughly 90th percentile and up) → next, as the strongest predictor of imminent exploitation.

4. High CVSS with real exposure → then, especially anything unauthenticated and internet-reachable. A 9.8 like F5 NGINX CVE-2026-42533 or VMware vCenter CVE-2026-59309 on an exposed surface belongs high, exploit or not.

5. Everything else → scheduled remediation, re-evaluated as EPSS and KEV change daily.

Two multipliers sit on top of that list. Asset exposure: the same CVE is a five-alarm fire on an internet-facing box and a low priority on an isolated internal one, so overlay reachability and business criticality. Compensating controls: a WAF rule, network segmentation, or a disabled feature can legitimately lower urgency while you schedule the real fix. Prioritization is a function of threat × exposure × impact, and CVSS only ever measured the last term.

What are the most common vulnerability prioritization mistakes?

The failures we see repeatedly all come from trusting one signal and skipping the context. The five most common:

• Sorting the queue by CVSS alone. The single most widespread mistake: it optimizes for theoretical severity and ignores whether anyone is exploiting the bug. It is how a CVSS 5.3 that's in KEV loses to a CVSS 9.9 that no one is attacking.

• Treating "not in KEV" as "safe." KEV lags and only lists confirmed cases. A public exploit with no observed campaign yet, GhostLock being the example, is dangerous today regardless of its KEV status.

• Trusting EPSS on kernel and local-privesc bugs. The model undersells exactly the categories where a reliable public exploit often lands first. For those, exploit evidence outranks the probability.

• Ignoring asset exposure. The same CVE is not the same risk on an internet-facing appliance versus an isolated internal host. Priority without reachability is just severity with extra steps.

• Scoring once and moving on. EPSS and KEV change daily; a priority set at scan time and never revisited is stale within a week. Re-scoring is not optional overhead, it is the point.

Each of these is a place where a number replaced a judgment. The fix in every case is the same: read the signals together, weight evidence highest, and overlay your own exposure.

Why point-in-time scans and annual pentests aren't enough

Because exploitation moves faster than the assessment calendar. When the median disclosure-to-exploitation gap is 26 days and one in five flaws is exploited on or before disclosure day, a quarterly scan or an annual pentest is structurally blind to most of what actually gets attacked. Our finding that 67% of 2025's actively-exploited vulnerabilities would have been missed by a once-a-year pentest is the direct consequence. EPSS and KEV both update daily; a prioritization model that only refreshes when a scan runs is reading yesterday's threat weather.

This is the core of Nexus Void's position: security has to be verifiable continuously, not confirmed once a year. Continuous verification means re-scoring your open vulnerabilities against fresh KEV and EPSS every day, re-checking which of your assets are actually exposed, and proving, with evidence you can hand to an auditor, that the ones being exploited in the wild are the ones you fixed first. A number in a scanner is a claim; continuous verification is the proof.

Our read

The trap in vulnerability prioritization is that CVSS is the easiest signal to act on and the weakest predictor of what will hurt you. The teams that get breached rarely ignored their 9.8s; they drowned in them while a "medium" like Cisco FMC or a kernel bug like GhostLock, the ones the score files under "later," were the ones actually being exploited. The fix isn't a better single number, it's a model that reads all three signals, weights hard exploit evidence above any score, overlays your real exposure, and re-runs every day. That is prioritization that reflects reality, and it is exactly the discipline the daily briefings linked throughout this page are built to demonstrate one CVE at a time.

Data sourced from NVD (CVSS/CWE), FIRST.org (EPSS), and CISA (KEV); exploitation-gap and pentest-miss figures from Nexus Void's analysis of 2025's actively exploited vulnerabilities. All per-CVE examples link to our full briefings above.

Explore the cluster: Cisco FMC CVE-2026-20316 · GhostLock CVE-2026-43499 · Windmill CVE-2026-29059 · Ubuntu snap-confine CVE-2026-8933 · Oracle EBS CVE-2026-46817 · SAP NetWeaver CVE-2026-44747 · Fortinet FortiSandbox CVE-2026-39808

Frequently asked questions

What is the difference between CVSS, EPSS, and KEV?
CVSS scores how severe a vulnerability could be (intrinsic impact, 0–10). EPSS predicts how likely it is to be exploited in the next 30 days (a probability updated daily). CISA KEV lists vulnerabilities with confirmed active exploitation in the wild. CVSS is severity, EPSS is likelihood, KEV is evidence, and you need all three.

Is a high CVSS score enough to prioritize a patch?
No. CVSS ignores whether anyone is actually exploiting the flaw, how exposed your instance is, and whether a public exploit exists. A CVSS 9.9 may not be under attack while a CVSS 5.3 like Cisco FMC CVE-2026-20316 is actively exploited. Combine CVSS with EPSS, KEV, and your own asset exposure.

Why does EPSS sometimes miss dangerous vulnerabilities?
EPSS is a statistical model trained on historical exploitation signals, so it undersells fresh kernel, container-escape, and local-privilege-escalation bugs that have a working public exploit but no observed campaign yet, such as GhostLock CVE-2026-43499. For those categories, weight "a public exploit exists" above the EPSS score.

Should I always patch everything in the CISA KEV catalog first?
Yes, as a baseline: KEV is the highest-confidence signal that exploitation is real. But KEV lags and only lists confirmed cases, so it's a floor, not a ceiling: a bug with a public exploit that isn't in KEV yet can still be urgent. Use KEV as an automatic top priority, not as your only filter.

How often should vulnerability priorities be re-evaluated?
Daily. EPSS and KEV both update every day, and the median time from disclosure to exploitation is about 26 days, with 20% exploited on or before disclosure day. A quarterly scan or annual pentest misses most real-world exploitation; continuous re-scoring against fresh threat data is the only model that keeps pace.

What is the best vulnerability prioritization model in 2026?
Order by evidence, then likelihood, then severity, overlaid with exposure: (1) in KEV, (2) public exploit exists, (3) high EPSS (~90th percentile+), (4) high CVSS on an exposed asset, (5) everything else on a schedule. Adjust for whether the asset is internet-facing and whether compensating controls reduce urgency, and re-run it daily.