Reserved but Public: The CVE IDs That Exist Everywhere Except the CVE List
A public advisory, a shipped fix, in some cases an exploit, and no CVE Record. The CVE Program calls these IDs Reserved but Public. On October 5 there were at least 1,983 of them, and every tool that reads the CVE List sees none.
On March 9, Red Hat published a flaw in dnf5, Fedora's package manager. It is a local denial of service, a path traversal in D-Bus locale handling that any ordinary user can reach, clocking in at a moderate CVSS 5.5. Red Hat shipped a fix on April 9. Debian, Ubuntu, and Amazon Linux all track it. It has an official ID: CVE-2026-3836. But if you pull the CVE List today, it is a ghost. Ask CVE Services directly, and for more than 200 days, you have gotten one line back: RESERVED.
The CVE Program has a name for this state, has had one since 2020, and approved a new policy for it on August 13. This post is about what that state costs you if your vulnerability management runs on the CVE List, how many of these IDs there are, and how long they stay that way.
TL;DR
A Reserved but Public (RBP) CVE ID is one a CNA has reserved and that a public advisory already cites, while the CVE Record itself is unpublished. Downstream, it does not exist: zero reserved records in the bulk CVE List, a 404 from the API endpoint most tools use, nothing in NVD, no EPSS score, nowhere for enrichment to attach. Your scanner learns about it when the record publishes. For the IDs that published while I watched, that was a median of 50 days after the first public advisory. On October 5 rbptracker.org listed 1,983 of these IDs, all public for at least a week, median 80 days, 321 older than six months, and that count is a floor. Exploitation does not wait for the record: 61 of the 1,734 entries in CISA's KEV catalog were added while the CVE was still reserved. The Program's rules give CNAs 72 hours. The fix for consumers is not to wait for the record: the distributions you already run publish the IDs your tools are missing.
Full disclosure up front: rbptracker.org is a RogoLabs project, my personal open-source lab, not an Empirical property. I serve on the CVE Program's Quality, Automation and Consumer working groups, and nothing here is a Program position. Data collected 2026-10-05 and 2026-10-06.
Key Statistics at a Glance
| Metric | Value, 2026-10-05 |
|---|---|
| Reserved but Public IDs listed by rbptracker.org | 1,983, a floor bounded by 18 feeds |
| Minimum age to be listed | 7 days publicly referenced, 2.3x the 72-hour window |
| Median days public | 80 |
| Older than 180 days | 321 (16.2%) |
| Share that are 2026 IDs | 1,677 (84.6%) |
| IDs that published while the tracker watched | 1,552; of 1,531 with a measurable duration, median 50 days, 2 inside 72 hours |
| KEV entries added before the CVE record published | 61 of 1,734 (3.5%); 3 of 250 in 2026 |
| Tracker rows in CISA KEV | 0 |
| CNAs whose published CVEs the tracker's feeds can see | 273 of 539 (50.6%) |
What Your Tools See When a CVE Is Reserved
| If you look here | You get |
|---|---|
| The bulk CVE List release | Nothing. The October 6 release holds 401,518 records: 383,085 PUBLISHED, 18,433 REJECTED, 0 RESERVED |
| The cvelistV5 git tree | Nothing. Reserved IDs have no file |
/api/cve/{id} |
404, the same answer as for an ID that was never allocated |
/api/cve-id/{id} |
The state, and a redacted owner |
| NVD | No entry |
| EPSS | No score. EPSS covers "every publicly disclosed vulnerability (CVE)" |
| CISA's ADP, or any other enrichment | Nowhere to attach |
| CISA KEV | Can list the ID anyway, and has |
The third row is the trap. Most tooling that checks whether a CVE ID is real asks /api/cve/, and for a reserved ID that endpoint returns the same 404 it returns for an ID nobody ever issued. The reservation endpoint, /api/cve-id/, returns the true state for any ID, unauthenticated, at 25,000 requests a minute. I did not know that in July, and the first version of my own tracker labeled every one of these IDs "does not exist" as a result.
The enrichment row is the one that compounds. CISA's Vulnrichment and every other Authorized Data Publisher add their CVSS, CWE and KEV flags to a published record. A reserved ID has no record, so the day it finally publishes it arrives bare, and the clock on enrichment starts then. A CVE Board member filed exactly this complaint against the record format in February 2023: RBPs mean "the CVE program consumers do not see any information about the CVE," and enrichment "can not add their value additions to the record until the CNA takes action to publish." It was closed in November 2024 as a Board-level decision.
Then there is the source I am closest to. EPSS scores are generated by Empirical Security for the FIRST EPSS SIG, and the FAQ says where the edge is: "Work is underway to extend scoring to vulnerabilities with reserved but not yet published CVE IDs." Today a reserved ID has no EPSS score because there is no record to score.
Exploited While Reserved
KEV is the one downstream source that does not wait for a record, which makes it a measuring stick. I joined the KEV catalog released October 4 to the CVE List and compared each entry's dateAdded with its record's datePublished, then checked every hit against NVD's own published date, which agreed on all of them. 61 of 1,734 KEV entries (3.5%) were added while the record was still reserved. Another 166 landed the same day the record did.
CISA KEV entries per year, with the segment added before the CVE Record published: 5 of 311 in 2021, 31 of 555 in 2022, 10 of 187 in 2023, 5 of 186 in 2024, 7 of 245 in 2025, 3 of 250 in 2026 through October 4
The median gap is 6 days. The long tail is a 2022 browser-vendor pattern: two Firefox zero-days added to KEV in March 2022 whose records published in December, 290 days later, and two Chromium V8 bugs at 116 and 102 days. That pattern has largely gone away: all three 2026 cases published the day after they were added. For every one of the 61, defenders had the vendor advisory and the KEV entry the whole time. Every tool keyed on the CVE List had nothing.
KEV is a floor for exploitation, not a census. None of the tracker's 1,983 rows is in CISA KEV, and I would expect that: KEV is small and the RBP population is mostly Linux packages and repository advisories.
How Many, and How Old
The tracker reads 18 public advisory sources, checks every CVE ID they cite against the reservation endpoint, and lists the ones that come back RESERVED once they have been public for seven days. It runs four times a day and names no CNA. The October 5 run:
How long the 1,983 Reserved but Public IDs have been public: 342 for 7 to 30 days, 860 for 30 to 90, 460 for 90 to 180, 321 for 180 days or more
1,677 (84.6%) are 2026 IDs. The rest are 39 from 2023, 112 from 2024 and 155 from 2025; the oldest was first cited in a CERT-Bund advisory in February 2023, 1,335 days ago. 1,939 (97.8%) are dated by an advisory more than 72 hours old. The other 44 are dated only by a distribution tracker entry, which the site does not treat as a disclosure clock. More than half the rows (1,051) come from repository-level GitHub advisories with no package ecosystem, which never enter GitHub's global advisory database; most of the rest come from the distributions (CSAF publishers, Debian, Ubuntu, Alpine, Amazon Linux, Red Hat) and from OSV.
Worth being clear about what "floor" means here. The tracker listed 522 IDs on August 22 with 9 feeds, 1,608 on August 26 with 13, a peak of 2,364 on September 10 with 17, and 1,983 on October 5 with 18. The August 26 jump is one feed coming online. The slide after mid-September runs the other way: between September 9 and October 5, 1,152 listed IDs got their record, faster than the feeds turned up new ones. When I first drew this chart in September it only went up, and I read it as a lesson about feeds. It is that, and it is also a lesson about the clock: the count is whatever is left after records publish, so it says very little on its own about whether CNAs are getting better or worse. The feeds see the published output of 273 of the 539 CNAs (50.6%) on the Program's list as of August 22, and that list has grown to 554 since. Half the Program is out of view, and the real number is higher.
rbptracker.org daily count from August 22 to October 5, 2026: rising from 522 to 2,364 in steps that coincide with new feeds (9, 12, 13, 14, 15 and 17), then falling to 1,983 with 18 feeds as listed IDs published
The question I get most is whether this is just publication lag. Since late August the tracker has watched 1,552 listed IDs publish, and every one of them checks out against the CVE List. Of the 1,531 with a measurable duration, the median had been public for 50 days when its record appeared, the fastest for 2, the slowest for 1,314. Two of the 1,531 (0.1%) made it inside 72 hours. That is a six-week window and a population that was already old when the tracker started, so it measures how long the ones that published had been public, not a typical RBP lifetime. It is enough to rule out latency. One thing the seven-day buffer cannot do is separate an overdue record from an embargo: a coordinated disclosure still in progress and a forgotten record look identical from outside, and some rows are legitimately held. The site says so rather than pretending the buffer settled it.
What To Do With This
If you patch for a living: do not let the CVE Record be your trigger. For the IDs in this post the fix usually shipped first, and the record shows up a median of 50 days later. Your distribution's advisory is the signal, so patch on it, and treat a CVE ID your scanner cannot resolve as a gap in the scanner rather than a sign the bug is not real. A 404 from /api/cve/ is not evidence that an ID was never allocated; ask /api/cve-id/. rbptracker.org publishes the current list as JSON and CSV four times a day, caveats attached, so you can check what you are missing. Empirical's RBP_TO_CVE project writes a predicted CVE 5.2 record for each one from what the distributions have published. Those records are tagged predicted, are never submitted anywhere, and on about half of them (399 of 822) the description is synthesized because no upstream wrote one. They are a stopgap, and today they are the best a consumer can do.
If you build scanners or feeds on the CVE List: your customers are the people in the paragraph above, and you have a blind spot the size of that table. Its shape is knowable. Read the distribution advisories directly, or read someone who does.
If you run a CNA: Shelby Cunningham of GitHub's CNA said it at VulnCon in 2024 after cleaning up GitHub's own backlog. Request IDs in small batches, publish on disclosure rather than at the end of the quarter, and check your reserved IDs against your own advisories. "Staying on top of CVEs and preventing RBP backlogs is less work than clearing backlogs."
If you work on the Program: publish the RBP count again, just like the Program did through 2021. I know the July 2026 minutes show an action item to evaluate broader visibility and reporting options. This is the easiest win. We do not need a public list naming and shaming CNAs. Just give the community the aggregate numbers, the age distribution, and the resolution rate. The rest of the policy can stay discretionary, but make the baseline reporting public.
A reserved ID is a promise that a record is coming. For 1,983 of them, at a floor, the advisory came, the fix came, in a few cases the exploit came, and the record has not. If your prioritization starts when the record lands, it is starting a median of 50 days behind the advisory, on exactly the bugs your distributions already patched.
A vulnerability does not wait for a published record to become a threat, and neither should your security data. Empirical customers get continuous signals on these exact gaps across their entire vulnerability portfolio, every day. See where you really stand at empiricalsecurity.com.
Methodology and Reproducibility
Reserved but Public list: rbptracker.org, run of 2026-10-05 15:15 UTC. The method, the 18 feeds and their caveats are at rbptracker.org/method and rbptracker.org/status. The daily history and the ledger of IDs that have since published are public on the data branch of github.com/RogoLabs/RBP.
CVE state: every reserved state in the post comes from the public CVE Services endpoint, cveawg.mitre.org/api/cve-id/{id}, which needs no account. Record counts are from the CVE List bulk release of 2026-10-06 in github.com/CVEProject/cvelistV5.
Exploitation: the CISA KEV catalog released 2026-10-04, compared on dateAdded against each record's datePublished, with every pre-publication case confirmed against NVD's published date.
Policy: CNA Rules v4.0, which set the 72-hour rule, and RBP Policy v2.0.0, both on cve.org.
Data collected and analyzed on 2026-10-05 and 2026-10-06.
