Pipeline status
Whether the most recent run was complete, what it read, and how often this site has actually published. Every count on the rest of the site comes from the run described here.
The last run
This run is incomplete. 1 feed(s) failed; 1 feed(s) stopped early, outside their configured limits; 2 feed(s) returned far fewer ids than last run. Every count on this site is a lower floor than usual and is not comparable to the previous run.
A run is marked incomplete when a feed failed outright, stopped for a reason that is not a configured cap, returned far fewer IDs than last time, or when the CVE Services reservation endpoint dropped rows. A configured page cap is not a degradation: it fires every run by design and is listed under standing limitations below.
| Snapshot | 2026-10-07 |
|---|---|
| Built | 2026-10-07 14:01 UTC (0.0h ago) |
| Code | 1d2e375649ac |
| Rows published | 2,032 |
Silent shrink detected. These feeds returned far fewer IDs than the previous run without failing or truncating, which is the one failure a status field cannot show:
- ubuntu: 3,996 -> 60 ids (98% fewer)
- ubuntu-osv: 30,120 -> 0 ids (100% fewer)
Does this site actually run every six hours?
20 of 28 scheduled runs published in the last 7 days (71.4%), most recently 2026-10-07T06:24:56+00:00.
This site also publishes on every merge to its main branch. Counting those, it published 21 times in the same 7 days, and the longest it went without publishing anything was 11.9 hours. A merge-triggered publish keeps the site fresh but is not evidence that the schedule fired, so it is not counted in the figure above.
Of the 28 ticks expected in that window, 20 published, 0 ran and did not publish, and 8 left no record at all. A tick that leaves no record never started. GitHub delays and drops scheduled workflows under load: on 2026-09-02 the four runs of the day began at 04:35, 11:19, 16:35 and 21:04 against a cron that asks for 00:17, 06:17, 12:17 and 18:17, and six of the 28 expected ticks never fired at all. That is worth seeing and it is not this pipeline failing, which is why the two are no longer added together.
The last figure is a residual rather than a measurement: it is what is left of the expectation after the runs that left a record. Ticks that ran and failed have only been recorded since 2026-09-02, so for the first week after that date this number still carries some of them.
Counted from a ledger appended by the step that actually publishes, so a run that built and failed to deploy is not counted as delivered. This exists because the six-hourly claim had no evidence behind it and was false at least twice: two scheduled ticks on 2026-08-21 produced nothing, with no pushes in the window, and nothing on the site could have told you. Until 2026-09-01 the figure above divided every publish by the scheduled ticks alone and read 164.3%, which could not have told you either.
What moved since the previous run
| Bucket | Rows |
|---|---|
| New | 74 |
| Published, verified in the CVE List | 2 |
| Rejected under rule 4.5.3.5 | 0 |
| No longer listed, cause unverified | 51 |
| Still open | 1,958 |
Only the first of those is good news. A row is counted as published only where the CVE List confirms a published record, taken from the resolution ledger rather than from the difference between two lists.
Rejected is not resolved. Rule 4.5.3.5 requires CNAs to reject unused or unpublished IDs, so rejection is lawful and is the likely end state for the oldest rows here. For anyone consuming the CVE List it is worse than an open RBP: the ID stays cited in advisories and no record is ever coming.
No longer listed means we do not know. A row leaves this list for reasons that have nothing to do with a CNA: a transient API error, a feed that failed or was truncated, a change to the feed set, a raised buffer, or a revised advisory date. None of those are a publication and none are counted as one.
CVE-2023-6396, CVE-2024-48943, CVE-2024-55919, CVE-2025-55662, CVE-2026-102478, CVE-2026-12841, CVE-2026-42783, CVE-2026-45098, CVE-2026-49861, CVE-2026-49862, CVE-2026-49863, CVE-2026-52047, CVE-2026-52048, CVE-2026-52050, CVE-2026-52051, CVE-2026-52052, CVE-2026-52055, CVE-2026-52056, CVE-2026-52057, CVE-2026-52058, CVE-2026-52059, CVE-2026-52060, CVE-2026-52062, CVE-2026-52064, CVE-2026-52065, CVE-2026-52066, CVE-2026-52067, CVE-2026-52069, CVE-2026-52070, CVE-2026-52071, CVE-2026-52072, CVE-2026-52073, CVE-2026-52075, CVE-2026-52076, CVE-2026-52078, CVE-2026-52079, CVE-2026-53588, CVE-2026-53589, CVE-2026-53590, CVE-2026-55063, CVE-2026-59986, CVE-2026-61547, CVE-2026-61626, CVE-2026-61627, CVE-2026-62268, CVE-2026-65107, CVE-2026-65140, CVE-2026-73278, CVE-2026-82373, CVE-2026-82374
Showing 50 of 51. The full list is in rbp.json by difference against the previous snapshot; it is deliberately not rendered, because a wall of identifiers reads as a finding and this bucket is explicitly not one.
Feeds read on this run
Every configured feed and what it returned. A feed that fails is reported here rather than simply yielding fewer rows, because counts are a floor and a silent shrink would read as improvement.
IDs read is how many CVE IDs the feed returned. Rows is how many of the IDs listed on this site that feed referenced, and Only source is how many of those no other feed referenced. The three are very different numbers, and a feed can return tens of thousands of IDs while accounting for none of the list.
A feed that reads from many third-party providers lists each provider beneath it. Capped on any of those rows means this site read only the newest advisories that provider publishes and stopped, which is a limit this site sets rather than anything the provider did. The note column says how many of how many. Those providers hold more than is counted here.
| Feed | State | IDs read | Rows | Only source | Note |
|---|---|---|---|---|---|
| acronis | OK | 147 | 2 | 0 | 147 ids from 248 advisories over 3 page(s) |
| alas | OK | 22,947 | 121 | 1 | 22947 ids |
| alpine | OK | 4,306 | 120 | 0 | 4306 ids |
| arch | OK | 95 | 0 | 0 | 95 ids |
| broadcom | OK | 1,341 | 7 | 4 | 1341 ids from 4966 advisories; 2844 of 4966 advisories list no id inline (floor) |
| certcc | OK | 314 | 14 | 14 | 314 ids |
| csaf | OK | 72,917 | 722 | 329 | 18 providers; 72917 ids; 1 read via pinned feeds; 1 no advisories in scope; see the provider rows below |
| csaf:advisories.ncsc.nl | OK | 14,373 | 14373 ids in scope; caught up across all 1,093 advisories this provider lists | ||
| csaf:advisories.stackable.tech | OK | 15 | 15 ids in scope; caught up across all 24 advisories this provider lists | ||
| csaf:cert-portal.siemens.com | OK | 2,834 | 2834 ids in scope; caught up across all 593 advisories this provider lists | ||
| csaf:csaf.data.security.nozominetworks.com | OK | 40 | 40 ids in scope; caught up across all 122 advisories this provider lists | ||
| csaf:intevation.de | OK | 6 | 6 ids in scope; caught up across all 6 advisories this provider lists | ||
| csaf:psirt.abb.com | OK | 155 | 155 ids in scope; caught up across all 74 advisories this provider lists | ||
| csaf:psirt.kunbus.com | OK | 15 | 15 ids in scope; caught up across all 19 advisories this provider lists | ||
| csaf:security.access.redhat.com | OK | 30,063 | 30063 ids in scope; caught up across all 49,775 advisories this provider lists | ||
| csaf:wid.cert-bund.de | OK | 60,248 | 60248 ids in scope; caught up across all 27,534 advisories this provider lists | ||
| csaf:www.cisa.gov | OK | 5,185 | 5185 ids in scope; caught up across all 2,647 advisories this provider lists via pinned feeds, its canonical metadata refused us | ||
| csaf:www.cisco.com | OK | 853 | 853 ids in scope; caught up across all 775 advisories this provider lists | ||
| csaf:www.huawei.com | OK | 0 | 0 ids in scope; caught up across all 0 advisories this provider lists | ||
| csaf:www.innomic.com | OK | 0 | 0 ids in scope; caught up across all 1 advisories this provider lists | ||
| csaf:www.open-xchange.com | OK | 118 | 118 ids in scope; caught up across all 22 advisories this provider lists | ||
| csaf:www.se.com | OK | 210 | 210 ids in scope; caught up across all 147 advisories this provider lists | ||
| csaf:www.sick.com | OK | 167 | 167 ids in scope; caught up across all 51 advisories this provider lists | ||
| csaf:www.suse.com | OK | 27,695 | 27695 ids in scope; caught up across all 98,109 advisories this provider lists | ||
| csaf:www.trendmicro.com | OK | 27 | 27 ids in scope; caught up across all 8 advisories this provider lists | ||
| debian | OK | 32,500 | 236 | 1 | 32500 ids |
| ghsa | OK | 18,064 | 119 | 0 | 18064 ids |
| ghsa-repos | OK | 13,737 | 1,164 | 977 | 13737 ids |
| jvn | OK | 2,566 | 5 | 3 | 2566 ids |
| mozilla | OK | 1,197 | 0 | 0 | 1197 ids |
| msrc | OK | 20,363 | 3 | 0 | 20363 ids |
| osv | OK | 21,886 | 260 | 60 | 21886 ids |
| osv:Android | OK | 2,171 | 2169 new of 2171 in-scope ids from 9MB | ||
| osv:crates.io | OK | 618 | 574 new of 618 in-scope ids from 4MB | ||
| osv:GitHub Actions | OK | 35 | 32 new of 35 in-scope ids from 0MB | ||
| osv:Go | OK | 3,563 | 3541 new of 3563 in-scope ids from 12MB | ||
| osv:Hackage | OK | 10 | 8 new of 10 in-scope ids from 0MB | ||
| osv:Hex | OK | 271 | 269 new of 271 in-scope ids from 1MB | ||
| osv:Maven | OK | 3,005 | 2931 new of 3005 in-scope ids from 10MB | ||
| osv:npm | OK | 4,083 | 4047 new of 4083 in-scope ids from 218MB | ||
| osv:NuGet | OK | 569 | 534 new of 569 in-scope ids from 3MB | ||
| osv:opam | OK | 17 | 17 new of 17 in-scope ids from 0MB | ||
| osv:Packagist | OK | 3,315 | 3280 new of 3315 in-scope ids from 11MB | ||
| osv:PyPI | OK | 4,103 | 4103 new of 4103 in-scope ids from 36MB | ||
| osv:RubyGems | OK | 387 | 356 new of 387 in-scope ids from 5MB | ||
| osv:SwiftURL | OK | 35 | 25 new of 35 in-scope ids from 0MB | ||
| redhat | OK | 28,649 | 105 | 0 | 28649 ids |
| samsung | OK | 604 | 29 | 11 | 604 ids |
| ubuntu | Truncated | 60 | 0 | 0 | error at offset 60: The read operation timed out; recovered 2 page(s) on retry |
| ubuntu:dates | Capped | 1 | dated 1 of 56 undated row(s) by name; 16 lookup(s) failed; the 600s budget was spent with 39 row(s) never asked for | ||
| ubuntu-osv | Failed | 0 | 0 | 0 | stream stopped after 0 ids: <urlopen error [Errno 104] Connection reset by peer> |
| zdi | OK | 4,415 | 45 | 30 | 4415 ids |
These feeds publish no dates at all, so their freshness cannot be checked by any threshold. That is not the same as checked and fine: alpine: returns no dated rows; arch: returns no dated rows; debian: returns no dated rows; ubuntu-osv: returns no dated rows
1 of 19 feed fetches failed.
- ubuntu-osv: stream stopped after 0 ids: <urlopen error [Errno 104] Connection reset by peer>
Standing limitations
These fire on every run, by design. They are not a fault and not a bad day; they are the permanent shape of what the feeds can see, and they are listed apart from the degraded state above because a warning that is always on is not a warning. Recording them as truncation made every single run read as incomplete.
- ubuntu:dates: dated 1 of 56 undated row(s) by name; 16 lookup(s) failed; the 600s budget was spent with 39 row(s) never asked for
The consequence worth stating plainly: a paginated advisory API read to a fixed cap is observed over a much shorter window than a distribution tracker read in full, so counts from the two are not directly comparable, and a CNA whose advisories arrive mainly through a capped feed will be under-represented here relative to one carried by a tracker.
How the count itself is built, what it excludes and how far the feeds reach is on the method page. The machine-readable version of everything here is in rbp.json, under degraded, degraded_reasons and feeds.