When two identities score the same CVE — a measurement of disagreement

A previous post on this blog showed that most records crossing a critical threshold carry no NVD score at all. This follow-up asks what happens when two identities do score the same record. The answer, measured against a local cache of the NVD 2.0 modified feed and the cvelistV5 hourly delta, is that disagreement is not an edge case; it is the majority state for any CVE with more than one score.

The cache holds 19,089 records, of which 18,365 are published and 724 are rejected. These records contain 25,831 stored score rows from 220 distinct publishing identities. Filtering to published records only, 17,704 carry at least one CVSS score. This leaves 661 published records with no score attached. Of the scored records, 6,191 have more than one stored score. Among those, 3,343 records show disagreement between their stored scores.

The magnitude of that disagreement matters for triage automation. 1,935 records disagree by at least 1.0. 726 disagree by at least 2.0. 227 disagree by at least 3.0. The average gap where scores differ is 1.32. The largest gap observed on a single record is 7.5.

For engineers writing filters, the most dangerous subset is not just any disagreement, but cross-identity divergence of significant magnitude. There are 453 published records where two different publishing identities assign scores that are at least 2.0 apart. Furthermore, among the 1,088 published records whose highest score is 9.6 or above, 131 also carry a score below 9.0, and 18 carry a score below 7.0. A filter keyed solely on "score >= 9.6" will catch the high mark but may obscure a conflicting assessment from another trusted source that places the same bug in a different severity band.

The measurement

The data was captured on 2026-11-14 from a local cache first built on 2026-11-11 and refreshed hourly. This cache combines the rolling 8-day window of the NVD modified feed with the newest cvelistV5 delta. Each score is stored with its originating feed, the publishing identity, the CVSS version, and the full vector string.

The analysis focuses on published records to exclude rejected entries that might skew aggregate averages. "Disagreement" is defined as any variance between stored scores for a single CVE ID. The qualification rule for high-severity thresholds (such as 9.6 or above) uses the highest score from any identity, with ties broken in favour of NVD, then CISA-ADP. CISA-ADP refers to CISA's Authoritative Data Provider container within cvelistV5.

How far apart they are

The distribution of severity gaps reveals a long tail of significant variance. While the average gap is 1.32, this mean hides the operational reality: nearly half of the disagreeing records differ by less than 1.0, but the remaining half includes substantial divergences that can shift a bug from "medium" to "critical" depending on which score is selected.

Gap Magnitude	Record Count	Percentage of Disagreeing Records (3,343)
< 1.0	1,408	42.1%
≥ 1.0	1,935	57.9%
≥ 2.0	726	21.7%
≥ 3.0	227	6.8%

The 453 records with a cross-identity gap of at least 2.0 represent the core challenge for automated triage. In these cases, two different organizations—often NVD and a CNA or ADP container—have looked at the same technical details and reached conclusions that differ by more than one severity level. This is not merely rounding error; it represents a fundamental difference in how impact, scope, or exploitability are weighted.

Five records, walked through

To understand why these numbers diverge, look at the vectors themselves. The score is a derivative of the vector; when the vector changes, the score follows. Five records, five different shapes of disagreement.

CVE-2026-116370: scope and blast radius

This record involves a fix in the Linux kernel stmmac driver for TSO DMA API usage causing an oops. It exhibits the largest gap measured in this dataset: 7.5.

NVD ([email protected]) assigns a CVSS 3.1 score of 9.6 with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H. The CNA ([email protected]) publishes three scores for this record:

• CVSS 2.0: 7.5
• CVSS 3.1: 6.3 with vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L
• CVSS 4.0: 2.1 with a vector beginning CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P.

The difference between NVD's 9.6 and the CNA's CVSS 3.1 score of 6.3 is driven by two metrics: S (Scope) and impact levels (C, I, A). NVD uses S:C (Changed), implying that the vulnerable component impacts resources beyond its security scope, combined with High impact on Confidentiality, Integrity, and Availability. The CNA uses S:U (Unchanged) and Low impact on all three metrics.

The CVSS 4.0 score of 2.1 goes the other way: UI:P treats user interaction as passive rather than absent, the three vulnerable-component impacts VC, VI and VA are all Low, and every subsequent-system impact is None. The supplemental and requirement modifiers are left at X (Not Defined). This suggests the CNA views the impact as contained within the vulnerable component and mitigated by user interaction or safety controls, whereas NVD views it as having broader systemic implications. The disagreement is not hidden; it is explicitly stated in the vector strings.

CVE-2026-41677: exploitability and attack complexity

This record concerns a security flaw in 2K Games Sid Meier's Civilization VI (version 1.0.12.68) in the loadstring function of the Lua sandbox.

NVD assigns a CVSS 3.1 score of 9.1. GitHub ([email protected]) assigns a CVSS 4.0 score of 1.7, with a vector starting CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:.

The drop from 9.1 to 1.7 is extreme, and the vector explains it: AT:P says attack requirements are present rather than absent, and VC:L caps the vulnerable-component confidentiality impact at Low. CVSS 3.1 has no metric for attack requirements at all, so nothing in NVD's 9.1 could express that reservation; the older family scores the bug as if reaching it were the only hurdle. The divergence here is CVSS 4.0's added modelling doing exactly what it was designed to do, on a record where the older number was inflated by comparison.

CVE-2026-31255: same version, different answers

This record presents a conflict within the same CVSS version (3.1).

NVD assigns 9.8. CISA-ADP assigns 5.4 with a vector prefix of CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:.

Here, both identities use CVSS 3.1. The difference lies in the Privileges Required (PR) and Impact metrics. NVD's 9.8 typically implies PR:N (None) and High impacts. CISA-ADP's vector indicates PR:L (Low) and Low impacts on Confidentiality and Integrity. This is a direct disagreement about how much privilege an attacker needs and how severe the impact is once exploited. It is not a version mismatch; it is a difference in technical assessment of the same bug.

CVE-2024-56719: the 10.0 outlier

In rust-openssl, where *_from_pem_callback APIs did not validate passphrase length (versions 0.9.0 to before 0.10.78), an ADP container identified by UUID 416baaa9-dc9f-4396-8d5f-8c081fb06d67 scores the record CVSS 3.1 = 10.0.

Both NVD and CISA-ADP score it CVSS 3.1 = 5.5. Their vector prefix is CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A: (availability only). The outlier's vector prefix is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:.

The disagreement centers on Attack Vector (AV:N vs AV:L) and Scope (S:C vs S:U). The 10.0 score assumes network reachability and changed scope with high impact. The 5.5 scores assume local access, unchanged scope, and only availability impact. This illustrates that a maximum-score filter would elevate this bug to Critical based on one container's view of network exposure, while two other major sources consider it Medium.

CVE-2006-4339: a 2006 record still being re-scored

Even records from 2006 are subject to re-scoring and disagreement. [email protected] scores this CVSS 3.1 = 9.1, while NVD retains a CVSS 2.0 score of 4.3. Because CVSS 2.0 lacks a Scope component, these numbers are not arithmetically comparable. However, the presence of a modern high-severity score alongside a legacy medium score in an active feed means that simple numeric filters may misclassify old bugs if they do not account for version differences.

CVSS 4.0 against 3.1, measured

There is a common assumption that CVSS 4.0 scores are consistently lower or more stringent than CVSS 3.1. The data from this cache contradicts that generalization.

Of the 4,917 records carrying both a CVSS 3.1 and a CVSS 4.0 score:

• The 4.0 score is lower in 1,780 cases.
• The 4.0 score is higher in 2,985 cases.
• The scores are identical in 152 cases.

Averaged over these pairs, the difference (CVSS 3.1 minus CVSS 4.0) is -0.23. This means that, on average, the CVSS 4.0 score is 0.23 points higher than the CVSS 3.1 score for the same record.

This finding is significant for automation. A system that downgrades severity when a CVSS 4.0 score replaces a 3.1 one will get the direction wrong on 61% of the records where both exist. The shift in scoring logic — mainly Attack Requirements and the split between vulnerable-system and subsequent-system impact — does not uniformly dampen severity; often it amplifies it or leaves it alone. Engineers must treat CVSS versions as distinct data types, not as interchangeable metrics that can be blindly averaged or compared without version-aware logic.

What to do on Monday

The data shows that relying on a single "official" score is fragile. 3,343 records have conflicting scores. 131 of the highest-severity records (>= 9.6) also carry scores below 9.0.

For patch triage automation and scanner rules, consider these implications:

1. Version-Aware Filtering: Do not mix CVSS 2.0, 3.1, and 4.0 scores in the same numerical filter without normalization or version checks. A CVSS 2.0 score of 7.5 is not comparable to a CVSS 3.1 score of 7.5.
2. Vector Inspection Over Score Trust: When scores disagree by more than 1.0, inspect the vector strings. Look for differences in S (Scope), PR (Privileges Required), and AV (Attack Vector). These are the metrics that drive the largest divergences. If a scanner supports it, flag records where S:C differs from S:U, or where AV:N conflicts with AV:L.
3. Bias Toward Worst Case: Taking the maximum score across all identities is a deliberate bias toward the worst claim made about a bug. It costs precision; you will triage some bugs as Critical that other sources consider Medium (like CVE-2024-56719). However, it mitigates the risk of ignoring a Critical assessment from a CNA or ADP when NVD is slower to update or scores differently.
4. Handle High-Variance Records Manually: The 453 records with cross-identity gaps >= 2.0 are not suitable for blind automation. They require human review of the vector differences. Automating a flag for "High Variance" (gap >= 2.0) rather than just "High Severity" can direct analyst attention to the ambiguous cases.
5. CVSS 4.0 is Not a Downgrade: Do not assume CVSS 4.0 scores are lower. They are higher in 61% of paired records. Update logic that expects a downward shift when new 4.0 scores arrive.

The disagreement is structural, embedded in the vectors and the differing perspectives of the publishing identities. Automation should reflect this complexity by flagging divergence rather than smoothing it over with a single number.