Why do different vulnerability databases sometimes assign different severity scores to the same CVE?

Why Vulnerability Databases Score the Same CVE Differently

Severity scores are not a single objective truth. Each database applies its own scoring model, editorial judgement, and update cadence, so the same CVE can look more or less urgent depending on whether the source prioritises exploitability, exposure, asset prevalence, or business impact. That makes score differences normal, but it also means teams should treat third-party severity as input, not final policy.

For security teams, the practical issue is less about which score is “right” and more about whether the scoring method matches the decision being made. A database that weights public exploit activity heavily may be useful for short-term response, while one that leans on technical impact may better support patch planning. In practice, many security teams discover the mismatch only after a vulnerability has already been queued, delayed, or escalated on the basis of a score that did not fit their environment.

When practitioners compare sources, they should look beyond the headline number to the scoring basis, published assumptions, and update timing. Public guidance from CISA cyber threat advisories is a useful reminder that current exploitation context can matter as much as static technical severity.

How the Scoring Models Diverge in Practice

Different databases often start from the same vulnerability record but then apply different filters. Some are closest to a technical scoring model that focuses on attack complexity, privileges required, user interaction, and the potential impact if the flaw is exploited. Others add contextual signals such as active exploitation, prevalence in the wild, vendor confidence, affected product reach, or whether the issue is easy to weaponise at scale. That is why one database may rate a vulnerability as moderate while another pushes it into a higher band.

There is also a timing problem. A severity score may be published before exploitation is known, then revised later when new telemetry appears. A score can therefore reflect a point in time rather than a lasting consensus. The same applies to metadata quality: if one source has incomplete product detail, unclear affected versions, or uncertain exploitability assumptions, its score may be more conservative or more aggressive than a better-informed source.

Practitioners should treat the score as a summary, not a substitute for analysis. The useful questions are whether the issue is reachable in your environment, whether compensating controls exist, whether exploitation would expose sensitive systems, and whether the vulnerability sits on an internet-facing or privileged path. A broad framework such as CIS Controls v8 is helpful here because it pushes teams toward asset visibility, secure configuration, and timely remediation rather than blind reliance on any single external rating.

In practice, the scoring disagreement matters most when teams confuse a published severity with an organisation-specific remediation priority, rather than validating it against exposure and control context.

When Score Differences Are Useful, and When They Mislead

Tighter scoring consistency can improve triage speed, but it also risks flattening local context, so organisations have to balance comparability against relevance. The best use of multiple databases is to understand why they disagree, not to average them mechanically.

Some differences are genuinely helpful. If one source highlights exploit activity while another reflects technical impact, the gap can reveal whether the issue is being driven by threat reality or by intrinsic flaw severity. That distinction can help separate “patch soon” from “patch immediately.” Other differences are less useful, especially when they come from outdated data, missing product context, or a scoring method that is not transparent about assumptions.

The edge case is when teams treat any high score as a universal emergency. That approach breaks down in environments with strong compensating controls, limited exposure, or nonstandard deployment patterns. It also fails in the opposite direction when a moderate score hides an internet-facing service, a privileged component, or active exploitation pressure. The right response is to combine external scoring with internal asset criticality and exposure.

If the question is being used to drive remediation policy, the practical limit is clear: score divergence stops being informative once the organisation cannot explain why one source is being trusted over another for a specific asset class or operational decision.

Practitioner Guidance

What to verify: Check whether the scoring source is describing technical severity, observed exploitation, or localised risk context before you use it in prioritisation. If two databases disagree, compare their assumptions rather than the score alone.

Decision rule: Use the external score to flag attention, then let your own exposure data decide urgency. A vulnerability that is internet-facing, exploitable on a privileged path, or already being targeted should outrank a higher numeric score on a dormant asset.

What practitioners underestimate: The biggest failure is not score variance itself, but using inconsistent scores as though they were interchangeable policy inputs. Teams need one internal prioritisation rule that reconciles external severity with asset value, reachability, and compensating controls.

Practitioner takeaway: Different scores are normal; inconsistent decision-making is not. Treat external databases as contextual signals, then anchor remediation order in your own asset and exposure reality.

Related resources from NHI Mgmt Group

• Why do severity scores fail in modern vulnerability management?
• Why do traditional severity scores often mislead vulnerability triage in containerised environments?
• Why do severity scores fail when vulnerability discovery becomes AI-driven?
• Why do vulnerability programs need portfolio context instead of relying on severity scores alone?