CVSS isn't enough: why the EPSS score changes how you prioritize vulnerabilities
A CVE rated "critical" isn't necessarily the one an attacker will actually use. Three real cases, pulled from our own scans, to see why.
October 18, 2026 · SunuCyberSecurity team
distinct CVEs identified to date by our automated scans
real exploitation probability (EPSS) of a CVE rated only "medium" by CVSS
real exploitation probability of a CVE rated "high" by CVSS
total CVE matches across our scans — too many to fix all at once
Source: our platform's vulnerability database + live EPSS score (FIRST.org) — data as of October 18, 2026
CVSS (Common Vulnerability Scoring System) answers one question: "if this flaw is exploited, how severe is the technical impact?" It says nothing about how likely someone actually is to exploit it. EPSS (Exploit Prediction Scoring System, maintained by FIRST.org) answers the other question: drawing on real-world exploitation data — mass scans, honeypots, public technical chatter — it estimates the probability that a given CVE will be exploited in the next 30 days. The two scores measure different things, and conflating them leads to poor prioritization.
The problem with CVSS alone
Our scans have identified 423 CVE matches to date, across 158 distinct vulnerabilities. Prioritize by CVSS score alone and a large share lands at "high" or "critical" — far more than any technical team can address at once. CVSS alone can't tell you where to start: it signals potential severity, not real, current risk.
Three real cases, pulled from our own scans
Here are three CVEs our platform actually identified (without naming which target — only the CVE matters here), with their CVSS score and their real EPSS score as of October 18, 2026:
Real exploitation probability (EPSS), three real CVEs
Source: live EPSS, FIRST.org — October 18, 2026
CVE-2023-48795 (Terrapin) — CVSS 5.9 "medium", EPSS 93.5%
A flaw in the SSH transport protocol that lets integrity checks be bypassed and some connection protections downgraded. Rated "medium" by CVSS, but its EPSS score puts it in the top 0.2% of CVEs most likely to be exploited — the exact opposite of what a CVSS-only prioritization would suggest.
CVE-2023-38408 (ssh-agent) — CVSS 9.8 "critical", EPSS 79.7%
Remote code execution via ssh-agent's PKCS#11 feature, if the agent is forwarded to an attacker-controlled system. Here CVSS and EPSS agree: high severity and high exploitation likelihood. This is the case where classic prioritization works well.
CVE-2026-60000 (OpenSSH, denial of service) — CVSS 7.5 "high", EPSS 0.6%
A denial of service from mishandled MaxAuthTries with GSSAPI authentication. Rated "high" by CVSS (resource consumption from repeated authentication attempts), but with an EPSS score near the median — nothing suggests it's actively targeted today.
How our scans prioritize today — and what's still missing
SunuAI Robot's security score already gives uncapped weight to critical findings and diminishing weight beyond the first ten high/medium-severity findings, so a scan with many results doesn't artificially crush the grade. But today, that calculation is based on CVSS, not EPSS — the Terrapin example above shows the limit of that approach well: real risk-based prioritization would mean combining both scores, not just adding up CVSS severities. This is an identified improvement, not yet implemented.
Live CVE database
Search our local CVE database (over 386,000 NVD entries) for a specific reference.
Methodology
The three CVEs cited were genuinely identified by scans run through the SunuCyberSecurity platform; no target or client is named. CVSS scores as recorded by our platform at scan time (cross-checked against the NVD database). EPSS scores fetched live from the public FIRST.org API on October 18, 2026 — these scores change daily, so the figures cited are a snapshot on that date, not a fixed value.
Related reading
Put this into practice
A free scan, in a few minutes, no credit card.
Free scan