A new RogoLabs site lists Reserved but Public CVE IDs: 2,315 of them on September 14, drawn from 17 public advisory feeds, refreshed every six hours, and held a week before they appear.
The first version of this tracker reported that none of the CVE IDs it found existed in the CVE List, in any state. It was July, the script was a week of evenings, and it asked the CVE Services API about every CVE ID cited in a pile of distribution and GitHub advisories but missing from the List. The API returned 404 for all 456 of them, so the report said DNE, does not exist, 456 times.
Every one of those IDs existed. They were reserved. I was asking /api/cve/, which answers 404 for a reserved ID and for an ID nobody ever issued, and cannot tell you which. There is a second endpoint, /api/cve-id/, that returns the real state for any ID, unauthenticated, and every one of my 456 came back RESERVED. Re-checked 32 days later, 224 of them had published, which is how I know they were real.
rbptracker.org is the corrected version of that script, run in public, with its mistakes written down. It is a RogoLabs project, which means my own time and nobody’s roadmap.
What a Reserved but Public CVE ID Is
The term is the Program’s own, not mine. It has been in the CNA Rules since version 3.0 in March 2020, the Program was charting RBP counts in its quarterly reports by 2021, and it is in the glossary and RBP Policy v2.0.0 today. The definition: a CVE ID in the Reserved state that a public source already references, while the CVE Record itself is unpublished.
The advisory is out. A reserved ID has no CVE Record yet, so the bulk CVE List cannot carry it: everything in cvelistV5 is PUBLISHED or REJECTED. The List is doing its job. It just means anyone who wants the reserved IDs has to build the list from somewhere else. NVD has no entry, EPSS has no score, and enrichment has nowhere to attach. A scanner that keys on CVE Records learns about the bug when the record lands. One fed by the distributions’ own data may already know.
RBP Policy v2.0.0, approved by the CVE Board on August 13, expects a record within 72 hours of the CNA disclosing, or of the CNA becoming aware that someone else did. I cannot see either moment from outside, so the site counts days public. It never says overdue. There is an enforcement process, and it runs inside the Program: no public list of RBPs, no log of who was notified. The one thing anyone can see is the state of each ID, so the state is what this site publishes.
Seventeen Feeds, Every Six Hours, Seven Days Before a Row Appears
Every six hours a GitHub Action reads 17 public advisory sources, pulls out every CVE ID they cite, and asks the reservation endpoint for each one’s state.
| Kind | Feeds |
|---|---|
| Distributions | Debian, Ubuntu (its tracker and its OSV export), Alpine, Amazon Linux, Red Hat, Arch |
| Vendors | Mozilla, MSRC, Samsung |
| Coordinators and disclosure programs | JVN, CERT/CC, ZDI |
| Aggregators | OSV, GitHub’s advisory database, GitHub repository advisories polled one repo at a time |
| CSAF | 18 publishers, Red Hat and SUSE to CERT-Bund and CISA |
RESERVED plus a public reference is a row.
Nothing gets listed until it has been public for seven days, more than double the 72-hour window, so a slow feed does not explain a row. What the buffer cannot do is tell an overdue record from an embargo. Nothing I can see from outside can, and some of these rows are legitimately held. There is no takedown form either. Every row is an ID the Program itself says is reserved, cited by an advisory that has been public for a week, and the row I cannot help is the accurate one that lands in the middle of somebody’s coordinated disclosure.
It publishes a static site plus JSON, CSV and a dated archive to GitHub Pages. No server, no database, and no credentials beyond the token GitHub Actions hands every workflow. The hosting bill is the domain.
| September 14 run | |
|---|---|
| Rows listed | 2,315, a floor |
| Median days public | 67 |
| Public 180 days or more | 312 (13.5%) |
| Public a year or more | 222 (9.6%) |
| Oldest | 1,314 days, a lone reference in a CERT-Bund CSAF document from February 2023 |
| 2026 IDs | 2,016 (87.1%); the rest are 152 from 2025, 110 from 2024, 37 from 2023 |
| Rows seen by exactly one feed | 1,458 (63.0%), 1,014 of them repository advisories no other feed can carry |
| CNAs the feeds have seen publish at least three times in the last four years | 268 of 539 on the roster (49.7%); 313 seen at least once; 49 of the 50 highest-volume |
Worth saying what two of those rows mean. “Days public” counts from the earliest date any feed shows me, which is a floor. For 55 rows that date is a distribution tracker entry rather than an advisory, and since nothing under a week gets listed, the median is over rows that had already cleared the buffer. The oldest row is exactly the kind I trust least. One reference, three and a half years old, is the row most likely to be a typo of a neighboring ID, and I have no way to check. 297 rows carry nothing but the ID.
And “floor.” The feeds see the published output of 268 of the 539 CNAs on the roster, so the other half is out of view no matter what it does, and the count went from 522 rows on August 22 with 9 feeds to 2,315 today with 17. That series measures how far the feeds reach and says almost nothing about whether RBPs are rising. The biggest step in it was one feed: repository-level GitHub advisories with no package ecosystem do not appear in GitHub’s global advisory database, and that feed alone accounts for 1,318 of today’s rows, 1,014 of which appear nowhere else.
The question I get most is whether this is publication lag. Since August 21 the tracker has watched 527 tracked IDs publish, and for the 514 I could time, the median had been public for 48 days when its record appeared.
That is three and a half weeks of closures from a population that was already old when the tracker started, and one batch moved it: 29 CVE-2023 IDs published on September 14, supplied most of the year-plus tail, and lifted the median from 41 to 48 overnight. So 48 days describes the IDs that happened to publish in three weeks, not a typical RBP. It does rule out the boring answer: these rows are not a feed running a day ahead of the List. I am not going to give you the share that published inside 72 hours. Nothing under a week old gets on the list, and the ten closures under seven days all predate that rule, so the number would be about my buffer, not about the Program.
Two More Things I Got Wrong
The wrong endpoint was not the only correction. Two more changed what the site is allowed to claim.
| What I believed | What turned out to be true |
|---|---|
| The policy had a 5% threshold I could measure the list against | That was RBP Policy v1.0, pulled from cve.org in January 2022 and still mirrored by third parties, which is how I found it. v2.0.0 has no numeric threshold. The scoreboard came out |
| A seven-day buffer would filter out coordinated disclosures | An embargo and an overdue record look identical from outside. No buffer length separates them. The buffer rules out latency, which is a narrower claim, and the method page now says so |
The rest of the list, including the morning the status page claimed a 164.3% publish rate, is in the repo’s NEXT.md and will probably be a talk.
The Thing I Actually Need: More Feeds
The most useful thing you can hand me is a source I am not reading. The count is bounded by what the feeds can see, and every feed on the site was scored before it went in. Two questions for any candidate: does it show me a CNA nobody else does, and has it ever cited a CVE ID before the record existed? EUVD fails the second. It publishes because a record published, so it can never be early. The feeds that pay off publish on their own clock: CERT/CC when coordination ends (300 IDs, 12 rows nobody else sees), ZDI when its disclosure timeline runs out (23 of its 38 rows the same).
So: a public page or feed that cites CVE IDs before the record publishes, fetchable without a login, in any format I can parse. Distribution security trackers, vendor PSIRT pages, CSAF endpoints, coordinator advisories, mailing list archives. I will run it through the same two questions and post the scorecard either way, merge or not. If you know one, open an issue with the URL and, if you have it, one CVE ID it cited while the ID was still reserved.
If You Consume the CVE List or Run a CNA
If you consume the CVE List: a 404 from /api/cve/ is not evidence that an ID was never allocated. Ask /api/cve-id/. And the feeds already in your stack publish these IDs weeks before the record does: the IDs this tracker watched publish had a median of 48 days in public first. The JSON and CSV are at rbptracker.org, refreshed four times a day, with the caveats in the same file as the rows.
If you run a CNA: check your reserved IDs against your own advisories. Everything on this list was cited in public by somebody. On today’s run that somebody is most often a GitHub repository advisory (1,318 of 2,315 rows), and 393 rows are cited by a distribution, which usually means the fix shipped before the record.
Full disclosure: I serve on the CVE Program’s Quality, Automation and Consumer working groups, and nothing here is a Program position.
Notes
- Site: rbptracker.org. The method, the policy quotations and the live pipeline health are at
/method.html,/policy.htmland/status.html. - Feed suggestions and anything else, including a row you think is wrong: github.com/RogoLabs/RBP/issues. The code that produced the row is public and so is the pull request queue. The two feed tests and every scorecard so far are in
FEEDS.mdandfeedlab/. - Code: github.com/RogoLabs/RBP, Apache 2.0. 190 commits between August 20 and September 13; the suite is 1,272 tests, 1,207 of which run offline in about 25 seconds on my laptop.
- RBP Policy v1.0 was removed from cve.org on 2022-01-25 per cve-website issue 835. The last CVE Program quarterly report I can verify carrying the RBP chart is Q2 CY2021, published 2021-07-28, in the old cve.org site archive.
- Every number above is from the 2026-09-14 run (summary generated 12:57 UTC, code
8a29a842ab74), saved indata/, and will have moved by the time you read this. The closure figures are from the tracker’s resolution ledger on its data branch, same date; its earliest closure is dated 2026-08-21.