Update 4.2.6 from SHOULD to MUST: "CNAs MUST assign different CVE IDs to separate Vulnerabilities"

[jayjacobs]

Existing wording:

4.2.6 CNAs SHOULD assign different CVE IDs to separate Vulnerabilities, as determined using the guidance in 4.1.

Proposed wording:

4.2.6 CNAs MUST assign different CVE IDs to separate Vulnerabilities, as determined using the guidance in 4.1.

See Cisco is Wrong and this response too.

[zmanion]

Check for other interconnected changes, including

4.2.11 CNAs SHOULDMUST assign different CVE IDs to different, Independently Fixable Vulnerabilities.

[zmanion]

Proposed changes that consolidate two rules:

4.2.6 CNAs SHOULDMUST assign different CVE IDs to separate, Independently Fixable Vulnerabilities, as determined using the guidance in 4.1.

4.2.11 CNAs MUSTSHOULD assign different CVE IDs to different, Independently Fixable Vulnerabilities.

Argument against this consolidation: Rule 4.2.6 is the general rule tied to the various ways 4.1 determines vulnerabilities to be
separate, while 4.2.11 addresses the specific case of independently fixable vulnerabilities and also provides context for 4.2.12 and 4.2.13.

[zmanion]

Proposed changes that split on CNA type, Supplier or other.

Comments received 5 PM Eastern time (2100 UTC) on 2026-09-16 will be considered during the Board vote.

4.2.6: A Supplier CNA assigning for its own product(s) MUST assign different CVE IDs to separate Vulnerabilities, as determined using the guidance in 4.1. All other CNAs SHOULD assign different CVE IDs to separate Vulnerabilities, as determined using the guidance in 4.1.

4.2.11: A Supplier CNA assigning for its own product(s) MUST assign different CVE IDs to different, Independently Fixable Vulnerabilities. All other CNAs SHOULD assign different CVE IDs to different, Independently Fixable Vulnerabilities.

cc @jayjacobs

[MathiasHollstein]

Concerns regarding the mandatory transition to "MUST" in section 4.2.6

Dear colleagues,

I would like to raise concerns regarding the proposed shift from "SHOULD" to "MUST" in section 4.2.6. There appears to be a growing misalignment between the technical reality of complex, interconnected vulnerabilities and the administrative drive toward granular, "one-to-one" CVE mapping.

I. Semantic vs. Technical Reality
The term "separate vulnerability" is insufficiently defined for complex systems (e.g., kernels, CPU microarchitectures). Many vulnerabilities are symptoms of a single underlying architectural flaw. Forcing a unique ID for every permutation of a side-channel attack creates "CVE sprawl," which reduces the utility of the CVE database for human assessment. Assigning five CVE IDs to a single architectural flaw creates a false impression of the software’s risk profile and the complexity of the remediation.

II. The "Independently Fixable" Fallacy
"Independently fixable" is dangerously ambiguous. In modern development, fixes are rarely binary; they are often bundled across complex supply chains. Does this rule imply that any fixable code snippet requires an ID? Forcing CNAs to artificially split a single, cohesive update into multiple CVEs creates an administrative burden that prioritizes documentation over actual remediation.

III. Alert Fatigue and Decision Noise
CVE IDs are a vital communication tool for system administrators. Converting a single advisory (e.g., a CPU microcode update) into 15+ CVE IDs leads directly to alert fatigue. For the end-user, this creates no actionable information—only additional checkboxes for compliance, inflating risk metrics without improving security.

IV. Infrastructure and Sustainability
If the policy becomes "MUST," every minor branch variation potentially becomes a CVE. Does the CVE Program and the broader CNA community have the infrastructure to support this level of granularity? Or will this lead to "zombie CVEs"—entries that are assigned but never meaningfully documented?

Conclusion
In my view, the CVE program is intended to be a communication protocol, not a granular software bug tracker. By forcing every minor issue to be tracked individually, the program risks becoming an administrative bottleneck. The true bottleneck for security is already in engineering and development departments; CVE inflation will only exacerbate the noise they must filter to focus on high-impact remediation.

I urge the board to reconsider the "MUST" requirement and instead focus on providing clearer guidance on when grouping is appropriate, rather than mandating fragmentation.

Thank you for consideration.

[ljharb]

@MathiasHollstein The quantity of CVEs doesn't say anything whatsoever about a product's risk profile or the complexity of the remediation - all it says is the number of different vulnerabilities that are known (the number that are not known/found, on every product, is "infinity", so having zero or minimal CVEs is simply NEVER a signal that there are no vulns, nor does it imply that the product is more or less secure, or more or less complex).

Do you have a concrete example of a vulnerability (like, an actual CVE ID) which would be impractical to separate into multiples under this new rule?

[MathiasHollstein]

Thank you for the clarification regarding the purpose of the CVE program. I agree that the count of CVEs does not directly equate to a product's security posture; however, the utility of the program does depend on its ability to provide actionable information to the end-users who must patch these systems.

Regarding your request for a concrete example, consider the architectural class of Transient Execution vulnerabilities. Landmark cases like Spectre (CVE-2017-5753, CVE-2017-5715, CVE-2017-5754) and Meltdown— specifically the Meltdown-BR and Meltdown-PK (CVEs unknown to me) variants — or more recent examples like Retbleed (CVE_2022-29900, CVE_2022-29901) and LVI / Load Value Injection (CVE-2020-0551), illustrate this perfectly.

If the "MUST" rule were applied to these classes, the requirement to assign unique IDs to every "independently fixable" variant would lead to administrative absurdity:

I. The Patch Chain vs. Fragmented IDs: A single microcode update or a monolithic kernel patch often addresses the entire architectural flaw (the root cause) rather than a single isolated "vulnerability." If a CNA is forced to assign a unique CVE ID to every minor variant found in different instruction sequences, a single, necessary firmware update — which is applied as a single binary blob — would require an arbitrarily long list of CVE IDs.

II. The Compliance Trap: Regulated environments require mapping CVEs to patches. Forcing an administrator to reconcile 20+ individual CVE IDs against a single microcode update creates a massive administrative burden that provides zero additional security value. It forces security teams to treat a single, cohesive fix as twenty separate, high-priority crises.

III. The "Independently Fixable" Ambiguity: In side-channel research, finding "variants" (like those within LVI or Retbleed) is an ongoing process. Because these variants are technically "fixable" in isolated code paths, the "MUST" rule mandates a continuous stream of new CVEs for what is, in practice, a single, persistent design limitation.

My question to the board is this: What is the tangible benefit to the end-user of having dozens of distinct IDs for a single microcode patch that addresses a shared underlying architectural flaw?

If the goal is to track "known vulnerabilities," a single ID for the architectural class, with sub-references for variations, would provide the same level of tracking without the administrative overhead and the "CVE inflation" that forces security teams to spend more time managing documentation than implementing remediation.

Thank you again for your consideration and for engaging in this discussion.

[nickleali]

To follow on to the previous point made by Mathias, the same observation applies to software issues such as the one described in CVE-2020-11022. Many individual instances of cross-site scripting vulnerabilities may be addressed by a single fix to one function. While this example existed in jQuery, the observation is true of other instances of XSS, where singular code improvements address discovered vulnerabilities in multiple endpoints.

Is it the intention to assign a unique CVE to each instance where any one of the updated jQuery functions is used in an unsafe way?

Or is it appropriate to use this CVE as a single reference that addressed multiple cascading issues in any application that implemented these features?

Similar examples come from Mozilla, see CVE-2026-2793, CVE-2024-6604, and others, where groups of memory corruption flaws are addressed by single code fixes or architectural changes.