RadicalNotion.AILast reviewed
A CVE record moves through a small set of states. It starts as Reserved when a CNA allocates an ID but withholds details, becomes Published when the vulnerability is disclosed with a description and references, and is Modified whenever the record is later updated. A record can also be Rejected if it turns out to be invalid or a duplicate.
A CVE record has a status that tells you where it is in its life. The main states are Reserved, Published, and Rejected, and Published records continue to be updated over time.
When a researcher or vendor needs an identifier before public disclosure, a CNA reserves a CVE ID. At this stage the ID is valid and citable, but the record carries no description -- it is a placeholder during coordinated disclosure.
This is why you sometimes see a CVE ID referenced in an advisory before any details are available: the ID was reserved ahead of the public Published state.
When disclosure happens, the CNA populates the record and it becomes Published. At this point the record includes a description, the affected products, and references to advisories and patches. Downstream systems like the NVD and CISA's Vulnrichment can now begin enriching it.
Publication is the moment the vulnerability becomes part of the public knowledge base that scanners, feeds, and the KEV catalog draw on.
A CVE is rarely frozen at publication. As new affected versions surface, patches ship, or descriptions are corrected, the record is updated -- reflected in its Modified date. Tracking the modified date matters because enrichment data such as CVSS scores and CPE lists can change after first publication.
Occasionally a CVE is Rejected. This happens when an ID was assigned in error, the issue is a duplicate of another CVE, or further analysis shows there is no real vulnerability. The ID is never reused; it stays withdrawn so old references do not point at a recycled flaw.