Reserved but Public · 2026-09-15

2,182 reserved, public, unpublished

A floor, not a total. Only configured feeds are read, and they reach 49.7% of CNAs. No row here is attributed to a CNA.

Grouped by

Public

This list is drawn in the browser, and scripts are switched off.
Every row is in rbp.csv and rbp.json, which carry the full set rather than the first hundred, with the field definitions in rbp.csv.meta.json. The method explains how the count is built and what it excludes.

Seen in

What is a Reserved but Public CVE ID?

A Reserved but Public CVE ID is one a CNA has reserved and that appears in a public advisory, while the CVE Record itself is still unpublished. Anyone pulling the CVE List sees nothing. The advisory is already out there.

The term is the CVE Program's own. Its glossary definition reads:

A CVE ID in the “Reserved” state that is referenced in one or more public sources but for which a CVE Record has not been published.

What the policy expects

RBP Policy v2.0.0, approved by the CVE Board on 13 August 2026, expects a record within 72 hours of disclosure, and sets out a real process: a Root notifies the CNA with a remediation timeline, CNAs must prioritise requests to publish critical RBPs, and repeat failures escalate up to decertification. That process runs inside the Program and is not visible in public data, so this site reports the state rather than the response to it.

Why no CNA is named here

The state itself is observable, and the CVE Services API will confirm it. What it will not tell you is who reserved the ID: "owning_cna": "[REDACTED]". CNA Rule 4.5.1.7 both permits and limits naming, and it binds the Secretariat rather than anyone else:

The Secretariat MAY publicly identify the CNA who reserved the CVE ID 24 hours after a CVE ID has been Publicly Disclosed. Otherwise, the Secretariat SHOULD NOT publicly identify the CNA until the CVE Record has been published.

So this site lists the identifier and the advisories it appears in, and leaves attribution to the Program. Ownership can be estimated from public data, and this version does not publish those estimates: the same reasoning that recovers an owner for a referenced ID would work across the whole reserved space, which is a good reason for the redaction to stay as it is.

What this measures, and what it does not

This is a Program-level transparency measurement, not a CNA scorecard. Which CNAs appear here is decided by how wide their ID blocks are and whether this site reads their advisories, not by how they behave: a CNA with large contiguous blocks and feeds we ingest is nameable, and one with neither is invisible no matter what it does. RBP Policy v2.0.0 also lets a Root direct a CNA-LR to publish an overdue record, so a row may be an ID delegated to a CNA rather than withheld by it, and nothing observable from outside distinguishes the two. The limits, in full.

What the policy says in the CNAs' favour

This site quotes the policy's hardest line at the top of this page. The same document carries four passages that cut the other way, and this project's own standard is that quoting only the parts that suit us would be selective. They are reproduced verbatim below, under the section headings they actually occupy, because two of them are not in Timely Publication and filing them there would misdescribe the policy.

Timely Publication

CNAs should ensure timely publication of CVE Records, “recognizing that such publication may, at times, coincide with ongoing vulnerability or incident response activities.”

“The CVE Program recognizes that internal processes may necessitate short delays; however, time flexibility allowed by the CNA Operational Rules should not be used to intentionally delay publication once an advisory or Fix has been made public.”

Notification and Remediation

The CNA is expected to publish RBPs as soon as possible and “no later than the deadline stated by their TL-Root or Root (which may account for factors such as volume, complexity, and resource constraints).”

Enforcement

“The CVE Program may take further action depending on the CNA's volume, history, and severity of RBPs.”

Taking those seriously changes what this site can claim, and it already has. Nothing is listed until it has been public for 7 days, which is 2.3x the 72-hour window and well past any short delay or live incident response. The median row here has been public 64 days, and 312 have been public more than 180 days. A short delay is not what this list is measuring.

And the last two passages license the sentence this whole site is built around: the only deadline that binds a specific row is one a Root set privately. It accounts for volume and resource constraints, it is not published, and no outside observer can see it. That is precisely why this site measures days public and never calls a single row overdue.

How this is measured

17 public feeds are read every six hours and everything they reference is checked against the CVE List. Nothing appears here until it has been publicly referenced for at least 7 days, which is 2.3x the 72-hour expectation, so ordinary latency and short coordinated-disclosure windows are excluded.

A source is who published the advisory, not who reserved the ID. Filtering to a publisher shows the IDs their advisories reference. The CVE Program redacts the assigner for reserved IDs, so this site cannot say who holds any of them, and does not.

The feeds reach a minority of CNAs, so every number here is a floor, never a census. The method in full, and the policy quotations.

The data

Everything on this page is in rbp.json and rbp.csv, with a dated archive at archive.json so a figure cited today stays resolvable. Schema and field meanings are in rbp.csv.meta.json.

Stable, not immutable, and the difference is deliberate. Each dated file is rebuilt from that day’s snapshot on every run rather than written once, and the archive keeps 90 days of dailies and then one snapshot per month, so a dated entry can eventually go away. This site does not operate a removal channel, publishes no address to request one, and has no lever to apply one: a row appears only after the CVE Services reservation endpoint confirms the ID is reserved and unpublished, and every row is an ID already referenced in a public advisory. What the archive will not do is keep serving a row the live list has dropped.