HAYROK LABS RESEARCH NOTE · HL-RN-2026-10Risk prioritization
How to prioritize vulnerabilities by exploitability, not CVSS.
CVSS was never a priority. Now it is often missing too.
The NVD stopped scoring most new CVEs in April 2026. This note swaps score-based ranking for four questions about what an attacker can actually use, and shows how to run them as code.
RULEEach question is cheaper than the next. Validation only runs on what survives the first two.
TL;DR
01
Since April 15, 2026, NIST fully enriches only a narrow slice of new CVEs. For most of them, the NVD will never publish a CVSS score.
02
CVSS was always a severity measure, not a priority. Exploitability signals were the better input all along, and now they are the only reliable one.
03
Further down: a four-question decision tree and a short script that ranks your findings using KEV, EPSS, reachability and validated verdicts.
Most vulnerability programs still rank findings by CVSS base score. That score describes how bad a flaw could be in the abstract. It says nothing about whether anyone is exploiting it, whether the code runs in your environment or what an attacker would reach. In 2026 a second problem showed up: the NVD stopped scoring most new CVEs at all. So let's replace score-based ranking with four questions built on exploitability signals, and run them as code.
Key findings
CVES MOVED TO "NOT SCHEDULED"
~29,000
NIST moved to risk-based enrichment on April 15, 2026. Full analysis is now reserved for priority CVEs such as KEV entries.
CVES WITHOUT ENRICHMENT
~80%
The Cloud Security Alliance warns that SLAs keyed to NVD CVSS scores may break for these.
NEW CVES EXPLOITED, 1H 2026
1.4%
VulnCheck counted 495 newly exploited vulnerabilities. Exploitation is concentrated.
EXPLOITED BY DAY ZERO
23.43%
Of those were exploited on or before the day the CVE was published.
KEVS FULLY FIXED IN 2025
26% · 43 days
Only a quarter of known exploited vulnerabilities were fully remediated, with a median of 43 days to resolution. Capacity is the real constraint.
A ranking signal that is missing for most CVEs, and was never about exploitation, cannot run a program that has to choose 1.4% out of 100%.
Why CVSS fails as a priority
CVSS is useful context. It just answers a different question than the one your remediation queue is asking.
It measures severity, not risk
The CVSS specification calls the base score a severity measure. Risk depends on threat and environment, which the base score leaves out.
It does not separate
A large share of CVEs score high or critical. When most of the backlog is a 9, the score cannot tell you which 9 to fix first.
It is increasingly absent
Many CVEs now carry only a vendor score or none at all. Rules like "fix all criticals in 15 days" silently skip them.
It ignores your environment
A 10.0 in a library that never loads is less urgent than a 7.5 on an internet-facing login path to customer data.
The method: four questions, in order
The tree borrows the spirit of CISA's Stakeholder-Specific Vulnerability Categorization (SSVC): ask a few decisive questions instead of computing one number. Each question removes noise before the next, more expensive one.
Q1
Is it reachable here?
Check runtime presence and exposure first. It is the cheapest filter and removes the most noise. Code that never loads, or a service no entry point can reach, is parked with a revalidation trigger.
No → P4, revalidate on change
Q2
Is there a threat signal?
Check the KEV catalog and the EPSS percentile. A KEV listing means exploitation is confirmed somewhere. An EPSS percentile of 0.95 or higher means it is more likely to be exploited soon than 95% of CVEs.
Not run → VALIDATE within 72 hours · contained → P3 · not exploitable → P4
Q4
What does it reach?
For proven exploitable findings, check the attack path. A path to a crown jewel makes it P1. Anything else is P2.
Crown jewel → P1 · otherwise → P2
Worked example: ranking five findings in code
Let's rank five findings that a CVSS-first program would treat as almost identical. Everything below uses public data feeds plus your own reachability and validation results.
python · priority.py
import json, urllib.request
KEV_URL = "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json"
EPSS_URL = "https://api.first.org/data/v1/epss?cve="
kev = {v["cveID"] for v in json.load(urllib.request.urlopen(KEV_URL))["vulnerabilities"]}
def epss_pct(cve):
data = json.load(urllib.request.urlopen(EPSS_URL + cve))["data"]
return float(data[0]["percentile"]) if data else 0.0
def priority(f):
if not f["reachable"]:
return "P4" # park, revalidate on change
if f["cve"] not in kev and epss_pct(f["cve"]) < 0.95:
return "P3" # validate in the normal cycle
v = f["verdict"]
if v is None:
return "VALIDATE" # run the five gates within 72 hours
if v == "not_exploitable":
return "P4" # suppress with evidence
if v == "exploitable_contained":
return "P3"
return "P1" if f["crown_jewel_path"] else "P2"
Feed it your findings, joined with reachability and verdicts from your validation runs:
Illustrative values. Run the script for live KEV and EPSS data.
The pattern is what matters. Under a CVSS-first rule, all five are urgent. Under the tree, one is a fix-now P1, one gets validated within 72 hours, and three wait for the normal cycle with a reason attached.
The last row is the new normal. A CVE with no NVD score still gets a defensible priority, because none of the four questions depend on CVSS.
How to measure the outcome
Five numbers that show whether the tree is focusing effort or just relabeling the backlog.
P1 share
The share of open findings in P1. A healthy tree keeps it small, because only proven paths to crown jewels qualify.
KEV time to verdict
Hours from a KEV listing to a validation verdict on every reachable instance.
Evidence-backed deprioritization
High-CVSS findings moved to P3 or P4 with a stored reason. Auditors will ask how you justified them.
Unscored coverage
The share of findings with no NVD CVSS score that still received a priority.
P1 time to fix
Median days from P1 verdict to verified closure.
How Hayrok approaches exploitability-based prioritization
The Hayrok Risk Engine runs this tree continuously, one engine per question.
Risk Engine
Ingests findings from the scanners you already own and enriches them with KEV and EPSS.
CodeFabrics
Supplies runtime data to answer the reachability question.
Answers the final question: does it reach a crown jewel?
Because none of the inputs depend on NVD enrichment, the ranking holds up even for CVEs the NVD will never score.
FAQ
Is CVSS useless for vulnerability prioritization?
No. CVSS describes the potential severity of a flaw and is useful context. It is not a priority, because it ignores active exploitation, reachability and impact in your environment.
What is EPSS and how is it different from CVSS?
EPSS, from FIRST, estimates the probability that a CVE will be exploited in the next 30 days. CVSS rates severity. EPSS rates likelihood, which makes it a better triage signal.
What did NIST change in the NVD in 2026?
On April 15, 2026, NIST moved to risk-based enrichment. Priority CVEs such as KEV entries are still fully analyzed, while many others will not receive NVD CVSS scores or product data.
What is the best way to prioritize vulnerabilities without a CVSS score?
Use exploitability signals: reachability in your environment, KEV status, EPSS likelihood and a validated verdict, then rank proven findings by what they reach.
How quickly should KEV-listed vulnerabilities be validated?
As fast as your process allows. Nearly a quarter of exploited CVEs in 1H 2026 were exploited by publication day, so a 72-hour verdict target for reachable KEV findings is a sensible start.
Rank your backlog by what attackers can use
Send us a sample of your critical findings. We will run the decision tree on them and show how the priority order changes.