On December 10, 2021, NVD published CVE-2021-44228 (Log4Shell) with a CVSS v3.1 base score of 10.0 — the maximum possible. Four days later, a related flaw, CVE-2021-45046, went out with a base score of 3.7, low severity, described as a denial-of-service issue in non-default configurations. On December 18, NVD revised that same CVE to 9.0, critical, after further analysis showed it also enabled remote code execution in default configurations. Same vulnerability, same database, three severity tiers in eight days. That is not an edge case — it is what CVE scoring looks like in practice, because CVSS is not one number produced by one authority. It is dozens of numbering authorities, NVD's own re-analysis, and vendor-specific advisories all scoring independently, often from incomplete information, on different CVSS versions, at different points in a vulnerability's disclosure timeline. Here is why the scores diverge and how to prioritize despite it.
Why do CVSS scores differ between NVD and vendor advisories?
They differ because NVD and the vendor CNA (CVE Numbering Authority) score the same flaw from different vantage points and often on different CVSS versions. A CNA — say, Red Hat, Oracle, or the project maintainer — scores based on how the vulnerability behaves in their specific product build, deployment defaults, and supported configurations. NVD scores based on a generic reading of the public advisory, frequently without access to the vendor's internal reproduction environment. This is why Red Hat rated several Log4Shell-adjacent CVEs differently from NVD's published scores: Red Hat's Attack Complexity and Scope values reflected how the flaw actually surfaced in their packaged distributions, not the worst-case generic scenario NVD defaults to. CISA's own vulnrichment initiative, launched in 2024 specifically to reduce this gap, still shows measurable score deltas between its CVSS v3.1 vectors and the original CNA-submitted vectors on a meaningful share of the CVEs it re-scores.
What caused the Log4Shell scoring swing from 3.7 to 9.0?
The swing happened because the initial analysis of CVE-2021-45046 assumed the flaw was only exploitable in non-default logging configurations. Researchers subsequently demonstrated that default configurations using a Thread Context Map pattern were also exploitable for full remote code execution, not just denial of service — a difference between "an attacker can crash your app" and "an attacker can run arbitrary code on it." NVD's revision from 3.7 to 9.0 on December 18, 2021 was a 5.3-point jump, one of the largest single rescoring events on record for a CVE already in active, widespread exploitation. Any team that had triaged CVE-2021-45046 as low-priority in the initial 48 hours — a defensible read of the published score at the time — was carrying an unpatched critical RCE for over a week without knowing it.
Why is the NVD backlog making scoring inconsistency worse?
It's making it worse because a growing share of published CVEs now carry no NVD-analyzed CVSS score at all, forcing downstream tools to fall back on inconsistent CNA-supplied scores or skip severity ranking entirely. NVD sharply slowed its enrichment work starting in February 2024, and by mid-2024 the unanalyzed backlog had grown into the tens of thousands of CVEs — vulnerabilities published to the CVE list with a description but no NVD-vetted CVSS vector, CWE mapping, or affected-product (CPE) data. When NVD doesn't score a CVE, scanning tools either display the CNA's self-reported score as-is, apply their own heuristic scoring, or leave severity blank. Three vulnerability scanners pointed at the same unscored CVE can legitimately produce three different severity labels, none of which is "wrong" by CVSS's own rules, because there is no canonical score to converge on.
How does CVSS v4.0 change the inconsistency problem?
CVSS v4.0, released by FIRST in November 2023, changes the inputs but doesn't eliminate the inconsistency, because adoption across databases remains partial and uneven. v4.0 replaced the ambiguous "Scope" metric with clearer Vulnerable System and Subsequent System impact scores and added optional Supplemental metrics like Automatable and Recovery that let scorers express real-world exploitation context CVSS v3.1 couldn't capture. In practice, as of mid-2026, most NVD entries and the majority of vendor advisories are still published with CVSS v3.1 or v3.0 vectors, some legacy entries still only carry v2, and only a minority of CNAs have moved to v4.0. A scanner comparing a v2-scored 2015 CVE against a v4.0-scored 2025 CVE is comparing numbers computed with different metric definitions, different weighting, and different assumptions about what "scope" even means — the scores are not on a truly common scale even though both render as "0 to 10."
What's the difference between CVSS severity and EPSS exploitability?
The difference is that CVSS measures theoretical severity if exploited, while EPSS (Exploit Prediction Scoring System) estimates the probability a vulnerability will actually be exploited in the next 30 days, and conflating the two causes teams to misprioritize. A CVE can carry a CVSS score of 9.8 and an EPSS probability under 1%, meaning it's catastrophic in theory but has shown no exploitation signal in the wild; another CVE can sit at CVSS 5.3 with an EPSS score above 90%, meaning it's actively and reliably being weaponized right now. FIRST.org, which maintains EPSS, has published data showing that a large share of actual exploitation activity concentrates in a small percentage of published CVEs — patch teams that triage purely by CVSS base score routinely burn cycles on high-severity-but-unexploited CVEs while lower-scored, actively-exploited ones sit unpatched. CISA's Known Exploited Vulnerabilities (KEV) catalog exists precisely because CVSS alone doesn't answer "is this being used against real targets today."
How should security teams handle conflicting CVE scores today?
Teams should treat any single CVSS number as a starting point, not a verdict, and triangulate against exploitation evidence and their own exposure before committing remediation effort. In practice that means cross-referencing the CNA score, the NVD score (when one exists), EPSS probability, and CISA KEV status for every CVE above a minimum severity threshold, then weighting the result by whether the vulnerable code path is actually reachable in the deployed application — a check that database scores, by design, never perform since they're assigned once for every downstream consumer of a package. A library flaw scored 9.8 by three different databases in perfect agreement is still a non-issue if the vulnerable function is never called in your build.
How Safeguard Helps
Safeguard is built around the assumption that no single vulnerability database gives you a trustworthy priority order on its own. Our reachability analysis traces whether a flagged CVE's vulnerable code path is actually invoked in your application, cutting through cases where CVSS, EPSS, and vendor advisories disagree by asking the more decisive question of exploitability in your specific build. Griffin AI correlates CNA, NVD, and EPSS data with your SBOM — generated automatically or ingested from existing pipelines — to produce a single risk-ranked view instead of three conflicting scores, and surfaces auto-fix PRs for the subset of CVEs that are both severe and reachable, so remediation effort tracks real risk rather than whichever database happened to score first.