CVSS 10.0. That was the base score FIRST.org's Common Vulnerability Scoring System assigned to CVE-2021-44228 — Log4Shell — within days of its December 2021 disclosure, and it was the correct technical verdict: unauthenticated, network-reachable, trivial remote code execution. But CVSS 10.0 told a security team nothing about whether their own specific Log4j deployment ever passed attacker-controlled input into a log statement that reached the vulnerable JndiLookup class — a fact that varied enormously from one application to the next. That gap between "theoretically as bad as it gets" and "actually exploitable in this environment" is the subject of this post. CVSS 3.1's base metrics — Attack Vector, Attack Complexity, Privileges Required, User Interaction — describe a vulnerability's worst-case shape in isolation, never whether it's network-reachable in your architecture, sitting behind an auth wall, or reachable at all from code your application executes. Industry data shows the resulting mismatch is not an edge case: multiple 2024-2025 analyses converge on the finding that only roughly 2-6% of all published CVEs are ever observed being exploited in the wild, despite a far larger share scoring 7.0 or above. This piece walks through why that gap exists, what CISA and FIRST.org built to close it, and how exploitability context changes what "critical" should actually mean.
What does a CVSS score actually measure?
A CVSS base score measures the technical severity of a vulnerability as a static, environment-independent property of the flaw itself — not the likelihood or feasibility of it being exploited against any particular target. FIRST.org, which maintains the standard, scores CVSS 3.1 base metrics from four axes: Attack Vector (Network, Adjacent, Local, or Physical), Attack Complexity (Low or High), Privileges Required (None, Low, or High), and User Interaction (None or Required), combined with impact metrics for confidentiality, integrity, and availability. Crucially, these describe the vulnerability's worst-case exploitation path as written into the CVE record — assuming an attacker can reach the vulnerable code at all. CVSS does include optional Temporal and Environmental metric groups meant to adjust for real-world factors like exploit maturity and deployment specifics, but FIRST.org's own data and multiple vulnerability-management vendors report that the vast majority of consumers only ever look at the base score, because temporal and environmental scoring requires manual, per-organization input that most scanning pipelines never populate.
Why do so few high-CVSS vulnerabilities get exploited?
Because CVSS scores the vulnerability, not the deployment — and deployment context is what determines whether an attacker can ever reach it. A CVE can score 9.8 because it describes unauthenticated remote code execution in a library's worst-case configuration, while in your actual codebase the vulnerable function sits behind authentication, is never called with attacker-influenced input, or is on a code path your build doesn't even compile in. Vulnerability-intelligence writeups analyzing EPSS versus CVSS data (including guides published by Indusface and the vulnerability-research blog resilientcyber.io covering "Vulnerability Exploitation in the Wild") consistently land on the same order of magnitude: somewhere around 2-6% of all published CVEs are ever confirmed exploited, a figure that has stayed roughly stable even as the annual volume of new CVEs has grown into the tens of thousands. Meanwhile, CVSS 7.0+ ratings are common — because attack-vector-network, low-complexity flaws are common in how software is architected, regardless of whether any given instance is ever internet-facing or fed attacker data.
What did CISA build to fix this, and how does it work?
CISA built the Known Exploited Vulnerabilities (KEV) catalog specifically because CVSS alone doesn't tell you what's actually under attack. KEV lists CVEs with confirmed, real-world exploitation evidence — regardless of their base score. Binding Operational Directive 22-01, issued in November 2021, originally required U.S. federal civilian agencies to remediate KEV-listed vulnerabilities on fixed deadlines independent of CVSS severity; CISA superseded it in June 2026 with BOD 26-04, which keeps KEV membership as a core input but replaces the flat deadline model with a graduated, risk-tiered remediation matrix. Either way, the underlying logic is unchanged: a CVE with a modest 5.3 base score that's on KEV because it's being actively weaponized still gets prioritized ahead of a 9.1 that has never been observed exploited. That inversion is the entire point: KEV membership is an observed-fact signal (someone saw this exploited), while CVSS is a theoretical-worst-case signal, and treating them as interchangeable is exactly the mistake that leaves real attack paths unpatched behind a backlog of technically-severe-but-inert findings.
How does EPSS complement CVSS instead of replacing it?
EPSS, the Exploit Prediction Scoring System maintained by FIRST.org — the same body that maintains CVSS — was built explicitly to fill the gap CVSS leaves open. Where CVSS answers "how bad would this be if exploited," EPSS answers a different question entirely: given everything currently observed about exploitation activity, scanning behavior, and public exploit code, what is the probability this specific CVE will be exploited in the next 30 days? EPSS outputs a daily-updated score from 0.0 to 1.0 per CVE, retrained continuously as new exploitation telemetry arrives, and FIRST.org is explicit that EPSS is designed to be used alongside CVSS, not as a substitute for it — a high-CVSS, high-EPSS finding is a very different priority than a high-CVSS, near-zero-EPSS one, even though both might read as "Critical" in a scanner's default severity column.
What does reachability add that even EPSS and KEV can't capture?
EPSS and KEV both describe exploitation likelihood in the wild in general — neither one knows whether your specific application ever calls the vulnerable function at all. Reachability analysis closes that last gap by building a call graph from your actual entry points down through your dependency tree and checking whether execution can reach the vulnerable line, the same distinction that made Log4Shell's real risk vary so widely by application even though every instance shared the identical CVSS 10.0 score. Safeguard's own prioritization engine, documented in its reachability-analysis capability, combines static and dynamic reachability with EPSS, KEV, and runtime/business context (production versus dev, internet-facing versus internal, regulated-data versus public) into a single priority score, and reports that reachability filtering alone typically removes 60-80% of findings from a team's "urgent" queue without dropping real risk — turning an open backlog of 200-500 CVEs into the 20-60 a week that actually deserve a sprint.
How should a team actually prioritize, then?
Prioritize on the combination, not any single signal: a CVE that is reachable in production, KEV-listed, and internet-facing deserves same-week remediation regardless of its exact base score, while an unreachable CVSS 9.8 in a dev-only container can safely sit in a backlog. In practice that means layering exploitability (EPSS, KEV, public PoC availability) and reachability (does your code actually call the vulnerable path, and is that deployment internet-facing) on top of CVSS rather than sorting a ticket queue by base score alone. None of these signals is individually sufficient — EPSS and KEV describe the internet's exploitation behavior, not your architecture, and reachability tools are conservative by design when code executes dynamically via reflection or eval, correctly refusing to suppress findings they can't verify as unreachable. The combination is what turns a scanner's severity column from a source of alert fatigue into an accurate map of where an attacker could actually get in today.