Preserving Vulnerability-Level Identification in a Time of Increased Disclosure Volume

Key Takeaway: The CVE Program does not support assigning a single CVE ID to multiple distinct vulnerabilities when those vulnerabilities are independently understandable, independently exploitable, independently fixable, or independently relevant to defenders. The CVE Program is committed to working with the community on scalable approaches that preserve vulnerability-level specificity.

Introduction

The CVE™ Program recognizes that vulnerability disclosure is under real and growing pressure. The volume and velocity of vulnerability discovery are increasing, and AI-assisted research, automation, and large-scale analysis are changing the pace at which vulnerabilities are found, reported, triaged, remediated, and published.

As part of the CVE Program's broader discussion on AI-enabled vulnerability discovery and scale, including the upcoming CVE Program community event on July 30, 2026, this post addresses one specific risk: preserving vulnerability-level identification.

The CVE Program is ready to work with CVE Numbering Authorities (CNAs), Roots, vendors, researchers, PSIRTs, vulnerability management teams, tooling providers, data consumers, and downstream defenders on practical ways to scale. The community needs both near-term improvements and longer-term solutions. But as new approaches are considered, one principle must remain clear:

A CVE ID identifies a publicly disclosed vulnerability. It is not a patch name, advisory name, release name, or bucket for groups of distinct issues.

The mission of the CVE Program is to identify, define, and catalog publicly disclosed cybersecurity vulnerabilities. That vulnerability-level specificity is not incidental. It is the foundation that allows the global defensive community to speak a common language about risk, exploitation, remediation, impact, and ecosystem-wide coordination.

Bundling Distinct Vulnerabilities Undermines the Purpose of CVE

The CVE Numbering Authority (CNA) Operational Rules state:

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

Yet, recent discussions across the vulnerability disclosure community have raised the possibility of assigning a single CVE ID to multiple distinct vulnerabilities, sometimes grouped by product release, patch, code area, weakness category, or remediation vehicle.

The CVE Program does not support assigning a single CVE ID to multiple distinct vulnerabilities when those vulnerabilities are independently understandable, independently exploitable, independently fixable, or independently relevant to defenders.

Bundling multiple distinct vulnerabilities under one CVE ID changes the nature of the CVE Program. It moves CVE away from being a vulnerability identification system and toward becoming a patch naming or advisory grouping system. That shift would have significant consequences for the entire defensive ecosystem.

A software update may remediate many vulnerabilities. An advisory may describe many vulnerabilities. A coordinated release may include many fixes. But the CVE IDs associated with those fixes must continue to identify the underlying vulnerabilities, not merely the release vehicle used to deliver remediation.

The community should distinguish between batching disclosure and bundling identification. Coordinating release dates, publishing multiple CVE Records together, aligning advisories, or improving automation may help organizations manage increased volume while preserving vulnerability-level specificity.

Why This Matters to Defenders

CVE IDs are used far beyond disclosure notices. They are embedded throughout the cybersecurity ecosystem as durable, machine-readable, widely understood identifiers. Security teams use them to prioritize remediation. Product security teams use them to coordinate disclosure. Researchers use them to connect technical analysis across sources. Vulnerability intelligence providers use them to enrich records. Data scientists use them to study trends. Governments and critical infrastructure operators use them to understand exposure and risk.

When multiple distinct vulnerabilities are collapsed into one identifier, that ecosystem loses precision.

Bundling can make it harder to determine:

• which specific vulnerability is being exploited
• which vulnerability has a proof of concept
• which products, versions, configurations, or components are affected
• which vulnerability has been remediated by a given patch
• which issue should be prioritized based on severity, exploitability, exposure, or asset criticality
• which vulnerability intelligence, detection logic, or mitigation guidance applies
• how to correlate vulnerability data across scanners, SBOM/VEX workflows, advisories, exploit databases, incident reports, and telemetry
• how to perform reliable trend analysis, metrics, and machine-learning research over time

This loss of specificity does not reduce risk for defenders. It shifts complexity downstream.

A bundled identifier may appear simpler at the point of publication, but it creates ambiguity for every user who must interpret, enrich, prioritize, detect, or act on the information afterward. Defenders need more clarity as vulnerability volume increases, not less.

A Call to CNAs and the Broader Community

The CVE Program asks CNAs not to bundle distinct vulnerabilities under a single CVE ID when those vulnerabilities should be identified separately.

The CVE Program continues to seek and value input from across the vulnerability community. We recognize that increased volume, AI-assisted discovery, and changing disclosure practices may require thoughtful changes to existing processes. Those changes should be collaborative, evidence-based, and fit for purpose, while preserving the vulnerability-level specificity that downstream users require.

We also invite community stakeholders to work with the CVE Program on practical ways to address increased volume. The community needs both short-term improvements and long-term solutions. Those solutions may include better tooling, clearer guidance, improved automation, more scalable reservation and publication workflows, enhanced enrichment, and updated practices for managing high-volume disclosures.

As part of the CVE Program's broader community discussion on AI-enabled vulnerability discovery and scale, we encourage stakeholders to bring their perspectives to the upcoming July 30, 2026, virtual community event — "CVE in an Era of AI-Enabled Vulnerability Discovery" — and related feedback channels. Input on high-volume disclosure workflows, CVE Record quality, downstream correlation, vulnerability enrichment, and the impacts of bundled identifiers will help inform practical next steps.

The CVE Program is committed to working with the community on these issues. We want to understand the operational pressures CNAs are facing, the needs of downstream users, and the ways current processes can be improved. We also welcome feedback on where existing guidance may need clarification.

But the central principle must remain intact:

A CVE ID should identify a publicly disclosed vulnerability.

Preserving that principle is essential to the CVE Program's mission and to the defenders, researchers, data scientists, vendors, governments, and users who rely on CVE every day.