Data quality issue with CVE-yyyy-nnnn

[RomanSpies]

OSV batch update 2026-04-01/02 broke GIT ranges for all OpenSSL advisories, causing false positives for any queried commit

Background

I have developed a C++ dependency analysis tool which ingests Conan lockfiles and utilizes the OSV determineversion and query API endpoints. Today, after roughly one week of pause, I ran a pipeline utilizing said tool on one of my C++ projects and was met with a large number of vulnerabilities which were not part of the report before — without changing either my conanfile or the version of my scanner used in the pipeline.

Reproduction

Query the OSV API directly:

Request:

POST https://api.osv.dev/v1/query
{
  "commit": "c9a9e5b10105ad850b6e4d1122c645c67767c341"
}

This is the commit hash for the openssl-3.6.1 tag. The response is 1.27MB and contains 70 CVE matches. Observe that the following are reported as affected:

• CVE-2016-0701 — only last_affected, no fixed, commit on 1.0.2 branch
• CVE-2025-9230 — five {"introduced": "0"} + {"fixed": "<branch-specific-commit>"} ranges, one per maintained branch
• CVE-2026-2673 — same pattern; 3.6.1 is itself the fix release for this CVE

Root Cause

On 2026-04-01 and 2026-04-02, all OpenSSL CVE advisories in the OSV database were modified in a batch update (70 advisories total, all carrying modified timestamps of those two dates). This update introduced GIT range structures that cause every commit in openssl/openssl to match as affected, regardless of actual version.

The affected advisories exhibit one or both of the following structural problems:

1. last_affected on diverged branches

Ranges of the form:

{"introduced": "0"},
{"last_affected": "<commit-on-1.0.2-or-1.1.x-branch>"}

are used for CVEs that have long since been fixed in the 3.x series. Since the last_affected commit shares no ancestor/descendant relationship with any 3.x commit, OSV cannot prove the queried commit is safe and conservatively reports it as affected.

2. Multi-branch fixed events with introduced: "0"

Even advisories that use fixed instead of last_affected have one range entry per maintained branch, each starting with {"introduced": "0"}. A commit on the 3.6.x branch is a descendant of the 3.6.x fix commit but has no ancestor relationship with the 3.0.x / 3.3.x / 3.4.x / 3.5.x fix commits. OSV matches the introduced: "0" on those ranges and cannot find a fixed ancestor, so it reports the commit as affected.

Impact

Any scanner querying by commit hash against https://github.com/openssl/openssl will receive false positives for all 70 advisories when using a current 3.x commit. Analysis of the response shows 56 are false positives from the structural issues above. The remaining 14 appear to be false positives for the same reason — 3.6.1 is itself the fix release for the most recent ones.

Prior to 2026-04-01 these advisories did not produce matches for 3.x commits. The batch update introduced the regression.

Expected Behavior

A commit that is the tagged release fixing a CVE, or any descendant thereof, should not be reported as affected. For multi-branch projects the correct data model requires either:

• (a) a fixed event per branch with a non-zero introduced scoped to that branch:

{"introduced": "<branch-start-commit>"},
{"fixed": "<fix-commit-on-that-branch>"}

• (b) ECOSYSTEM ranges with version strings alongside the GIT ranges, so that version-based queries are unambiguous.

[github-actions]

✨ Thank you for your interest in OSV.dev's data quality! ✨

Please review our FAQ entry on how to most efficiently have this addressed.

[G-Rath]

This aligns with changes to the osv-scanner snapshots