In the CVE Record Format, a record's state is either PUBLISHED or REJECTED. PUBLISHED means the ID carries a real description, affected products and references. REJECTED means the ID should not be used, and the record carries the reasons instead. A rejected ID is not a live vulnerability, so remove it from your backlog.
The two states in the schema
The CVE Record Format is a JSON schema maintained in the CVE Project's public repository. Its metadata block has a state field, and the schema describes it as "State of CVE: PUBLISHED, REJECTED."
The two states use different shapes. A published record must include provider metadata, descriptions, affected products and references. A rejected record must include provider metadata and a list of rejected reasons, and it does not need the product detail. That difference is useful in practice: if you parse CVE data yourself, branch on state before you look for affected versions.
What the dates tell you
The metadata block can carry several timestamps, all optional in the schema:
| Field | What it records |
|---|---|
| dateReserved | When the ID was reserved |
| datePublished | When the record first appeared in the CVE List |
| dateRejected | When the ID was rejected (rejected records only) |
The schema adds a caution about the first one: the reserved date does not necessarily reflect when the vulnerability was discovered or disclosed. Do not use it to compute how long a bug sat unfixed.
Why an ID gets rejected
The schema does not list reasons, only that a rejected record must explain itself. Teams commonly see an ID rejected because it duplicates another ID, or because the issue turned out not to be a vulnerability. Read the rejected reasons text rather than guessing, since that is the authoritative statement.
What to do in your own tooling
- Treat REJECTED as closed. Do not open tickets for it, and close any that exist with a note pointing to the rejected reason.
- If the reason names a replacement ID, track that ID instead.
- Re-check on a schedule. A record can move from PUBLISHED to REJECTED after you triaged it, so a stale local copy can send engineers after a ghost.
- If you publish your own advisories, remember the reverse case: when you assign an ID to an issue that later turns out to be a duplicate, reject it with a clear reason instead of deleting it. People may already link to it.
For how IDs are requested in the first place, see who to ask for a CVE ID.
Try it yourself
Click through it at your own pace, or open it full screen.
Click a finding and look at how status is tracked, since a rejected ID is one of the ways a finding should close.
Quick check
Is a REJECTED CVE ID a real vulnerability?
No. The record is retained so the ID is not reused or silently lost, but it should not be treated as a vulnerability. Read its rejected reasons for the explanation.
Does the reserved date show when a bug was found?
No. The schema says the reserved date does not necessarily reflect when the vulnerability was discovered or disclosed.
Safeguard's SBOM and dependency scanning keeps findings tied to current advisory data, and you can try a free scan on your own project.
Sources
Last reviewed: 19 October 2026.
