Who actually scores a critical CVE — a measurement of one 8-day feed window

The finding

Buyers and engineers triage CVEs on a CVSS number and assume the number comes from NVD. It usually does not. A measurement run on 2026-11-14 against a local cache of the NVD 2.0 modified feed, refreshed hourly since 2026-11-11, shows that among published records whose highest score from any identity is >= 9.6, only 176 carry any score from [email protected]. The remaining 912 do not. That is 8 in 10 critical-severity records in the feed arriving with no NVD-generated CVSS at all.

The number that carries this finding is not just the absence of an NVD score. It is what replaces it. Of those 1,088 high-scoring records, [email protected] provides the highest score on 142. CISA-ADP—the Authoritative Data Provider container that CISA adds to cvelistV5 records for enrichment and KEV-related context—provides the highest score on 21. The remaining 925 are decided by the record's own CNA or by another of the 220 identities. When you filter on "score >= 9.6", you are not filtering on an NVD judgment. You are filtering on whichever identity happened to publish a score that crossed the threshold first, and in most cases that identity is neither NVD nor CISA-ADP.

How the window was collected

The measurement covers a local cache of the NVD 2.0 JSON modified feed plus the newest cvelistV5 hourly delta, first built 2026-11-11 and refreshed hourly since. The cache holds 19,089 records: 18,365 published, 724 rejected. The modified feed is a rolling 8-day window of everything published or modified within it, so this sample represents roughly 11 days of accumulated deliveries, not a month's worth of data. Every score row in the cache retains the publishing identity, CVSS version and vector string as delivered by the feed. Nothing here is estimated; every figure traces to a stored record.

Who the scores come from

Across all 25,831 stored CVSS score rows in the cache, there are 220 distinct scoring identities. This is not a small tail of occasional contributors. The distribution inside the 1,088 high-severity records alone tells you who is actually deciding what counts as critical.

Identity	Score rows in >=9.6 set
CISA-ADP	442
[email protected]	180
[email protected]	155
[email protected]	117
CNA containers (cvelistV5)	105
[email protected]	86
416baaa9-dc9f-4396-8d5f-8c081fb06d67 (org UUID)	67
[email protected]	43
[email protected]	42
[email protected]	33

CISA-ADP produces more than twice as many score rows in the critical set as NVD does. VulnCheck and VulDB together contribute 272 rows, more than NVD's 180. The CNA containers themselves—scores assigned by the vendor or researcher who originally reserved the CVE—contribute 105. GitHub Security Advisories contributes 86. IBM, Oracle and Microsoft each contribute scores that can become the highest on a record when they disagree with every other identity.

This is not a quality ranking. It is a provenance map. When your scanner reports 9.8 for CVE-2026-31255, that number was produced by one specific identity using one specific vector string under one specific CVSS version — [email protected], CVSS 3.1, and CISA-ADP publishes 5.4 for the same record. The NVD feed does not tell you which identity's score your tool picked unless you look at the source field on each metric object. Most triage automation does not look.

What NVD's workflow state actually says

If you filter on "NVD analyzed" as a proxy for trustworthiness, the data shows what that filter excludes. Among the same 1,088 records with a highest score >= 9.6:

NVD workflow state	Count
Analyzed	372
Deferred	275
Modified	224
Awaiting Analysis	155
Undergoing Analysis	54
Received	7

Only 372 of 1,088 are in Analyzed state. That is roughly one-third. Another 275 are Deferred, meaning NVD has decided not to analyse them further. 224 are Modified: changed upstream after NVD last processed them, which is often exactly when a new score from another identity arrives. 155 are still Awaiting Analysis. If your triage rule is "act on anything NVD has analysed", you are missing 716 of the 1,088 records that already carry a score >= 9.6 from some other identity.

The gap between "score >= 9.6" and "NVD Analyzed" is not an edge case. It is the majority case. NVD's CVSS metrics page describes how its analysis programme works and what happens when a CNA publishes a CVSS v3.x score of its own: the CNA score is carried as published. Enrichment is also rationed by workflow state, and a record in Deferred will not be enriched at all. The score you see on day one may therefore never be confirmed or contradicted by NVD.

CVSS 4.0 as a filter

CVSS 4.0 adoption is often treated as a forward-looking signal: if your scanner supports CVSS:4.0, you are ready for the next generation of scoring. In this window, it mostly is not present where it matters. Of the 1,088 high-severity records, the highest score is:

CVSS version	Count
3.1	1,051
4.0	22
2.0	8
3.0	7

CVSS 4.0 is the highest version on only 22 records. CVSS 3.1 dominates at 1,051. A filter that keys on CVSS:4.0 as a vector prefix will miss over 97% of the critical set in this window. This does not mean CVSS 4.0 is irrelevant; it means that right now, filtering on version 4.0 is functionally equivalent to filtering on "almost nothing." The version distribution reflects which identities have migrated and which have not, not which scores are more accurate.

The practical consequence: if your triage automation branches on CVSS version, verify that the branch logic handles records where the highest score is 3.1 but a secondary identity has published a 4.0 score at a different magnitude. The "highest from any identity" rule used in this measurement breaks ties in favour of NVD, then CISA-ADP, but your scanner may apply its own tie-breaking logic that produces a different result on the same record.

KEV as the reality check

The CISA Known Exploited Vulnerabilities catalogue version 2026.11.13 holds 1,781 entries. Of those, 30 appear in this 8-day modified window; the rest are older and no longer delivered by the feed. Of those 30 KEV-listed records:

• 9 carry a highest score >= 9.6.
• 19 carry no NVD score at all.

That means roughly two-thirds of actively exploited vulnerabilities in this window have no NVD-generated CVSS. They may have scores from other identities, but if your automation waits for an NVD score before triggering action, those 19 are invisible to you until a non-NVD identity publishes one—and some of them may never get one while they remain in Deferred or Awaiting Analysis state.

KEV is not a scoring authority. It is an exploitation signal. But its intersection with the scoring data shows that the set of vulnerabilities being exploited and the set carrying an NVD score are not the same set: on this window they overlap on 11 of 30 records. An engineer who treats "NVD scored" as a prerequisite for urgent triage will systematically under-prioritise known-exploited flaws.

The practical implication for Monday morning

The measurement says three things about any filter you run today.

First, a filter built on [email protected] as the sole scoring identity silently drops 912 of 1,088 records that already meet your severity threshold. If your automation logic is "score >= 9.6 AND source == [email protected]", you are seeing roughly one-sixth of the critical set. If it is "score >= 9.6" without a source filter, you are seeing all of them but do not know whose number you are reading, which means you cannot reproduce or defend the decision when someone asks why CVE-2026-XXXX was escalated on Tuesday and downgraded on Friday because a different identity published a lower score.

Second, "NVD analyzed" as a workflow filter excludes 716 high-scoring records. Deferred is not a rejection; it is a statement that NVD will not look further. Awaiting Analysis means the record may sit unchanged for weeks or months while other identities have already scored it. If your SLA depends on NVD reaching Analyzed state, you are binding your response time to a queue depth you do not control.

Third, CVSS version is not a proxy for recency or accuracy in this data. 1,051 of 1,088 critical records carry a 3.1 score as their highest. A filter on CVSS:4.0 catches 22. If your scanner's CVSS 4.0 support is the reason you bought it, verify that its fallback to 3.1 scores does not silently discard secondary metrics or apply different threshold logic per version.

The actionable step is not to switch sources. It is to store the publishing identity and vector string alongside every score your system records, and to surface them in triage interfaces. The CVE record format keeps containers.cna and containers.adp separate for a reason: different identities can and do assign different scores to the same CVE using different vector strings under different versions. Two scores of 9.8 on the same record are not interchangeable if one is AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H from a CNA and the other is a CVSS 4.0 vector from an ADP with different scope assumptions. The vector string is the only way to compare two scores of the same record, and it is the field most triage dashboards discard.

Check whose number you are reading before you act on it.