MITRE's own CNA-LR records routinely fail to meet 5.1.3 and 5.1.7 (product and vulnerability type identification)

[jgamblin]

The CNA Operational Rules require, without exception, that every CVE Record identify an affected product and a vulnerability type:

• 5.1.3: MUST identify at least one affected Product using information such as Supplier and Product names, versions, and dates.
• 5.1.7: MUST identify the type of Vulnerability.

Across MITRE's own CNA-assigned records in cvelistV5 for 2025-2026 (5,905 records), the structured fields for these are placeholder text far more often than not:

• 83.9% list vendor and product as literal n/a in the affected data element.
• 83.7% list the vulnerability type (problemTypes description) as n/a.
• 83.4% carry no CVSS or other metrics from the CNA container at all.

Every other major CNA checked (GitHub, Patchstack, VulDB, Microsoft, Adobe, Apple, Oracle, ~30 largest by volume) sits at 0% on the product and type fields. Some of those CNAs also skip CVSS themselves (Chrome and Apple are 100% no-CNA-metrics), but that's a different situation: NVD or CISA reliably backfills it as an ADP, and the required identifying fields (product, type) are still populated correctly by the CNA. MITRE's gap is in the fields the rules say MUST be present, not the optional scoring.

Example: CVE-2026-24114. MITRE's CNA container has vendor: "n/a", product: "n/a", version: "n/a", and a problem type description of "n/a". CISA, acting as ADP, later added the real CWE (CWE-120) and a CVSS 3.1 score of 7.5. The reference MITRE already had in hand (tenda.com.cn) names the vendor and product directly, so the information needed to satisfy 5.1.3 was available at the time of publication.

Anticipated counterargument, addressed directly

5.1.3 doesn't say product identification has to happen in the structured affected element specifically, and 5.2.2 explicitly allows the prose description to carry information not provided elsewhere in the record. So it's fair to ask whether MITRE is actually in violation, or just using the description field instead.

I checked. Sampled 200 random MITRE records with n/a in the structured affected field. All 200 name a real vendor and product in the prose description: D-Link DIR-853, TOTOLINK A3002R, Quest KACE Systems Management Appliance, phpMsAdmin, CKFinder, and so on. This isn't missing information, it's a consistent pipeline pattern of putting real product data in free text and leaving the structured field as a placeholder.

That distinction matters and should be explicit in the rules rather than left to interpretation. The structured affected element exists because it's what makes product identification machine-parseable for every downstream consumer (vulnerability scanners, SBOM matching, CNA scorecards, this analysis itself). A vendor name buried in a sentence doesn't serve that purpose, even though a human reading the description can find it.

Note also that 2.4.3 (the CNA-LR efficiency exemption from notifying suppliers and publishing advisories) doesn't cover this. It exempts CNA-LRs from 4.3.2 and 4.5.2.1, not 5.1.3 or 5.1.7.

Proposed changes

1. Amend 5.1.3 to: "MUST identify at least one affected Product using the affected data element(s) of the CVE Record Format, with information such as Supplier and Product names, versions, and dates." This closes the loophole 5.2.2 leaves open by naming the structured element explicitly, rather than leaving product identification satisfiable by prose alone.
2. Clarify 5.1.7 similarly if CNAs are found using n/a problemTypes descriptions while naming the CWE-relevant weakness only in prose.
3. Alternatively, if the Program intends to allow placeholder structured values as a stopgap pending ADP enrichment, say so explicitly rather than leaving it as an unstated practice inconsistent with the literal text.

Methodology note: analysis script and full per-CNA breakdown available on request, happy to publish to RogoLabs if useful for the review.

[jayjacobs]

This seems completely reasonable and I wish I could add a few hundred thumbs up to it.

[jess-lowe]

As a downstream consumer focused on machine automatable vulnerability records, here are a series of filler words I've had to filter out for when parsing some parts of the CVE records:

"n/a",
"unknown",
"unspecified",
"not-known",
"tbd",
"to be determined",
"-",
"latest",

In many cases, the actual version, or vendor information is available in the description, which is a lot harder to parse programmatically. 'latest' is not useful with no context given, as it is only relevant at time of publication.

[boblord]

I strongly support this proposal. 

A bigger point is this: the Program's "Quality Era" only means something if CVE Records are machine usable, not just machine readable. Those aren't the same thing. A record can be written in valid JSON and still dump the real work on every downstream consumer because the data that should be in a structured field (vendor, product, versions, weakness type) was never put there. That seems to be the case with the records in your analysis: the reference already named the vendor and product, and it still didn't make it into the structured fields. Someone downstream is forced to re-derive what the CNA meant instead of just ingesting the record and using it.

CVE-2026-24114 shows exactly why this can't be solved downstream either. CISA came in after the fact and added the real CWE and a CVSS score. That's the pattern we need to break, not just for this record but as a habit. If ADPs can quietly repair whatever a CNA leaves incomplete, there's no pressure on the CNA to get it right the first time, and "the ADP will catch it" becomes a permanent excuse. Records need to be complete and accurate at creation. ADP enrichment should be additive, not a backstop for CNAs skipping the fields the rules already require.

So how did records with this failure rate get published in the first place? My understanding is that at least some of these are written directly to the database, bypassing the CVE Record Format API and its validation path entirely. If that's right, no amount of tightening the rule text fixes this by itself, because a direct write never goes through the thing that's supposed to enforce it.

The AWG's validation library work is the right fix, but only if it's universal. Once it's integrated, every CNA needs to create and modify records through it, no exceptions, including CISA and MITRE's own CNA-LR. No direct database writes from anyone, short of a documented, logged exception. A validated path some people can skip isn't really a validated path.