A CVE record is in one of three states. Reserved means an ID is set aside but has no public details. Published means the record has an ID, a description and at least one public reference. Rejected means the ID should no longer be used, though it stays on the list so people can see it is invalid.
The three states, as the CVE program describes them
CISA's documentation on the Known Exploited Vulnerabilities catalog summarizes the CVE record lifecycle this way:
| State | Meaning | What you can do |
|---|---|---|
| Reserved | The initial state, when a CVE Numbering Authority (CNA) reserves the ID | Wait, or ask for publication through the CVE request process |
| Published | The CNA has filled in the record: ID, prose description and at least one public reference | Triage normally |
| Rejected | The ID and record should no longer be used. It stays on the CVE list so users can tell it is invalid | Close or re-map findings |
A CNA is an organization authorized to assign CVE IDs for products in its agreed scope. It can be a software vendor, an open source project, a coordination center, a bug bounty provider or a research group.
Reserved: the ID without details
You may see a CVE ID in a news story or a vendor note while the record is still Reserved. There is nothing to scan against yet. Details may be held back while a fix is prepared. Do not build a rule from a Reserved ID. Instead:
- Note the ID in your watch list.
- Read the vendor advisory text if one exists. It may contain affected versions even though the CVE record is empty.
- Recheck the record in a few days.
CISA notes that visitors can request that a Reserved record be published by submitting a request to MITRE through its form. That is for cases where the vulnerability is already public. Think of it as a last step, not a first one.
Published: where triage starts
A Published record has a description and references, but it may still be thin. It is not required to list every affected version. Add data from the vendor's advisory and from the sources you trust. Do not wait for a severity score to start. A missing score does not mean a missing risk.
One related point from CISA's KEV criteria: a CVE ID is the first of three requirements for the catalog, followed by reliable evidence of active exploitation and clear remediation guidance. So a vulnerability with no CVE ID cannot appear in KEV at all, even if attackers use it. Keep vendor advisories on your watch list, not just CVE feeds.
Rejected: clean up your tickets
A Rejected record means the ID should no longer be used. Because rejected IDs stay on the list, your scanner may still carry them for a while. When one appears in a ticket:
- Confirm the state on the CVE list, not only in the scanner.
- Look for a replacement ID in the record notes.
- Close the ticket with a note that links the Rejected state, so the audit trail is clear.
- Tell your scanner owner so the data gets cleaned up.
Try it yourself
Click through it at your own pace, or open it full screen.
Open a finding and see which fields come from the record and which come from your own triage. Keep the two apart in your notes.
Safeguard dependency scanning tracks advisories as they change and ties them to your SBOM. A free scan shows it on a real project.
Quick check
Is a Reserved CVE a real vulnerability?
It means an ID has been set aside. Details are not public in the record yet, so look at the vendor advisory and recheck later.
Why does a Rejected CVE stay on the list?
CISA's summary says it stays so users can know the ID is invalid.
Sources
Last reviewed: 19 October 2026.
