CVE Record States: Published, Rejected and Disputed, and What Each Means for Vulnerability Triage

A CVE ID (Common Vulnerabilities and Exposures identifier) looks like a settled fact: a number for one specific flaw. In practice the record behind it can be rejected, disputed, about a product nobody supports, or about a service you cannot patch. If your triage process treats every CVE ID in a scanner report the same way, it will waste effort on some and under-react to others. This guide explains the states and tags the CVE Program defines, shows real records, and suggests how to handle each case.

Scope. This is research-based analysis plus one script we ran. On October 16, 2026 we read the CVE Record Format schema (the CVEProject/cve-schema repository on GitHub, main branch), its tag definitions, and the CVE Program’s CNA Operational Rules version 4.2.0 (approved August 20, 2026, effective August 25, 2026). We fetched records from the CVE Services API and queried the NVD (National Vulnerability Database) API. We did not read the CVE Program’s policy for disputing a CVE record, which the rules reference. For how CISA adds triage fields in an ADP container, see Vulnrichment SSVC values.

Who writes a CVE record

The schema’s own description says the record format is the blueprint that CVE Numbering Authorities (CNAs) and Authorized Data Publishers (ADPs) use to describe a CVE record. A CNA is an organization authorized to assign CVE IDs within a defined scope. The schema says a record has at least one cna container, with exactly one allowed because only one CNA assigns the ID, and any number of adp containers added by other organizations. The CNA container must carry certain fields; an ADP container does not have to.

That split matters for triage. Everything you read in the cna container is the assigning organization’s statement. Anything in an adp container, such as CISA’s SSVC fields, was added by someone else.

The two states: PUBLISHED and REJECTED

The schema defines a record as either “Published” (when a CNA populates the data for the ID) or “Rejected”, and the state field in cveMetadata has only those two values. IDs that have been reserved but not yet published have no public record in this format that we could find; we did not test how the API presents them.

Source: the schema’s cveMetadataPublished, cveMetadataRejected and cnaRejectedContainer definitions.

Why records get rejected

The CNA Operational Rules (version 4.2.0) say:

• CNAs must reject unused or unpublished CVE IDs (rule 4.5.3.5).
• CNAs may reject a published record. Common reasons include determining that no vulnerability exists, using an incorrect CVE ID, a duplicate assignment, or combining multiple IDs (4.5.3.6).
• A rejection must use the CVE Program’s formats and must include an explanation (4.5.3.7).
• When IDs are merged, the redundant published IDs must be rejected (4.5.3.8).

Two real rejected records

We fetched both from the CVE Services API on October 16, 2026.

Neither record’s replacedBy field was present, even though CVE-2024-1992’s reason names a replacement in free text. If you automate “follow the replacement”, parse the reason text as a fallback and do not assume the structured field is populated. We examined only these two records, so we cannot say how common that is.

Tags: disputed, unsupported-when-assigned, exclusively-hosted-service

The schema defines tag lists. CNAs can use three tags, and ADPs only one.

Sources: the schema’s cna-tags.json and adp-tags.json, and CNA rules 4.2.17.1 (CNAs must use unsupported-when-assigned where all affected products no longer receive fixes), 4.5.3.10 and 5.1.11.

On disputes, the rules say CNAs and the Secretariat must use the disputed tag and provide an explanation in the record (4.5.3.10), and that CVE Program members must show the disputed status and the explanation when displaying CVE record data (4.5.3.11). The disputed tag marks a disagreement; it is not a verdict. The CNA rules point disputes to a separate CVE Program policy that we did not read.

What these look like in real records

The affected-products list of CVE-2020-35235 says vendor “n/a”, product “n/a”, version “n/a” with status “affected”, so a scanner cannot match it by version from the CVE record alone.

Two points follow. First, the disputed record in our example questions whether the issue is a vulnerability at all. Its EPSS score is low, but a low score is a probability estimate, not proof that the dispute is right. Second, an end-of-life tag does not mean low risk: EPSS, which estimates the probability of observed exploitation activity in the next 30 days, put CVE-2020-35235 at the 97th percentile in the file scored 2026-10-15. See our EPSS data feed guide for how to read that column.

The affected-status field: affected, unaffected, unknown

Inside a published record, each product version has a status of affected, unaffected or unknown. The schema says unknown means it is unknown or unspecified whether a version is affected, for reasons including that no investigation has been done or the vendor has not disclosed the status. The CNA rules require every record to identify at least one product as affected or unknown (5.1.4), say CNAs should resolve unknown status within a reasonable timeframe, and add that a permanent unknown may be appropriate, for instance when a product is suspected of being affected but has not been investigated (5.1.6). A record may not contain only unaffected products (5.1.8).

For triage: unknown is not a clean bill of health, and a version listed as unaffected is only as good as the CNA’s analysis.

How big are these categories?

We queried the NVD API on October 16, 2026. NVD is a separate database that ingests CVE records, so its numbers describe NVD’s data, not the CVE List itself.

We inferred the rejected count by subtraction; we confirmed that CVE-2019-1508 has vulnStatus “Rejected” without the parameter and returns no results with it, and that CVE-2024-1992 has vulnStatus “Rejected”. The EPSS file we used elsewhere held 389,824 scored CVEs, close to the 390,296 non-rejected count but not identical. We did not investigate the 472-record gap, and the two files were queried hours apart.

A triage playbook

These steps are our suggestions, not part of any CVE Program rule, and we did not test them in a production queue.

A tested script to read state and tags

This script fetches a record from the CVE Services API and prints the fields above. It uses only the Python standard library. The endpoint is a public API; we did not need a key for single-record lookups, but bulk queries returned a message that a CVE-API-ORG header is required.

import json, sys, urllib.request

def triage_view(cve_id):
    url = f"https://cveawg.mitre.org/api/cve/{cve_id}"
    rec = json.load(urllib.request.urlopen(url, timeout=30))
    meta = rec["cveMetadata"]
    cna = rec["containers"]["cna"]
    out = {"cve": meta["cveId"], "state": meta["state"],
           "assigner": meta.get("assignerShortName"),
           "updated": meta.get("dateUpdated")}
    if meta["state"] == "REJECTED":
        out["rejectedReasons"] = [r["value"] for r in cna.get("rejectedReasons", [])]
        out["replacedBy"] = cna.get("replacedBy", [])
    else:
        out["cnaTags"] = cna.get("tags", [])
        out["adpTags"] = [t for a in rec["containers"].get("adp", [])
                          for t in a.get("tags", [])]
        out["statuses"] = sorted({v["status"] for p in cna.get("affected", [])
                                  for v in p.get("versions", [])})
    return out

if __name__ == "__main__":
    for cid in sys.argv[1:]:
        print(json.dumps(triage_view(cid)))

Run on October 16, 2026 against five IDs:

{"cve": "CVE-2024-1992", "state": "REJECTED", "assigner": "Wordfence", "updated": "2024-03-20T16:44:07.699Z", "rejectedReasons": ["Rejected as duplicate of CVE-2024-2306"], "replacedBy": []}
{"cve": "CVE-2019-1508", "state": "REJECTED", "assigner": "microsoft", "updated": "2020-01-24T21:14:20.000Z", "rejectedReasons": ["DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was in a CNA pool that was not assigned to any issues during 2019. Notes: none"], "replacedBy": []}
{"cve": "CVE-2026-14683", "state": "PUBLISHED", "assigner": "VulDB", "updated": "2026-07-16T07:18:18.631Z", "cnaTags": ["disputed"], "adpTags": [], "statuses": ["affected"]}
{"cve": "CVE-2020-35235", "state": "PUBLISHED", "assigner": "mitre", "updated": "2024-08-04T17:02:07.522Z", "cnaTags": ["unsupported-when-assigned"], "adpTags": [], "statuses": ["affected"]}
{"cve": "CVE-2021-44228", "state": "PUBLISHED", "assigner": "apache", "updated": "2025-10-21T23:25:23.121Z", "cnaTags": [], "adpTags": [], "statuses": ["affected"]}

Known limits of the script: it assumes the record has a cna container and reads tags only from tags; it does not follow the version ranges inside affected; and it makes one request per ID, so do not run it over a whole scanner export without caching and rate limiting. A real pipeline should also handle HTTP errors, which we did not test.

Limits of this article

We examined two rejected records, one disputed record and one end-of-life record out of hundreds of thousands, chosen for illustration, so they do not show how typical records look. Record contents and NVD counts change over time. We did not read the CVE Program’s dispute policy and did not investigate NVD’s own status labels such as “Deferred”.

Sources and verification

Checked on October 16, 2026.

Vulnerability ManagementFundamentals