Large batch of NVD→OSV CVE conversions disappeared after 2026-05-04, still missing

[0roman]

We noticed a large batch (multiple thousand) of previously-valid CVE conversions vanished and haven't come back.

Concrete example: CVE-2021-32024 and CVE-2024-48856

Timeline from our mirror's history:

• Until 2026-05-04, both had valid, non-withdrawn OSV records.
• On 2026-05-04, in a single sync, withdrawn was added to both (modified/withdrawn: 2026-05-04T08:37:33Z and 08:39:45Z respectively) — and to ~136k other CVE records in that same sync.
• As of a fresh sync in July 2026, both (and ~135k of the previously-cached CVE conversions total) are entirely absent from current output — not present-with-withdrawn, just gone.

Timing correlation we noticed: this window sits right between #5290 (2026-04-30, "nvd-cve-osv Cron job doesn't seem to be successfully finishing") and #5099 (2026-05-05, GCS upload pipeline rewrite with hash-based skip-if-unchanged uploads).

Question: did a partial/failing run in that window write bad withdrawn tombstones for a large batch of CVEs, and could the new hash-based skip-upload logic in #5099 be preventing those from ever being regenerated since? Is there a way to force reconversion for affected CVEs?

[jess-lowe]

I'm pretty sure that all of those records were not actually valid OSV records (to the quality that OSV would like to ingest) in that they would not have had proper affected fields as they are closed source records. (we don't want them as they aren't able to be matched to anything programmatically)

We mistakenly generated the records at some point, and when we did a generation that didn't convert them (as they aren't valid), they were withdrawn.
We then did a cleanup of these invalid records as the withdrawn was causing too much confusion as in the OSV context it can both mean "not valid for this database"/"not converting anymore"/"it was rejected upstream" - hence why you aren't seeing them anymore.

Concrete example: CVE-2021-32024 and CVE-2024-48856

These are both examples of closed source vulnerabilities (both existing in Blackberry). We only generate CVE records for what we can produce an affected field for - which is anything where we are able to extract both a version, and a repository in order to derive affected commits.

Technically, it is still possible to generate these records locally if you really wanted them but it's likely a little complicated.

Hope this helps! Let me know if you find any records in your dataset that are open source, and I'm happy to investigate further.

[0roman]

That was already helpful. Thanks for the details. We were mostly interested in understanding the reason behind it. We were surprised by the amount of CVEs deleted.