Data quality issue. CVE-2026-86145 not reported on pcre2, possibly others are missing as well

[kikofernandez]

Describe the bug
Hi there from Erlang/OTP team.

We have been using OSV to do our vulnerability scanning using the REST API, and OSV is great!

However, we have noticed recently that some of the reporting (data quality) seem to be incorrect.

We discovered that we are possibly affected by a pcre2 issue and we were wondering if OSV should have alert us in the CI pipeline that we have, which relies on OSV.

This is the information we send using the https://api.osv.dev/v1/querybatch REST API:

{
  "queries": [
    {
      "commit": "37d575ede5ade50ad95b857f22ed7f1be4b1f2df",
      "package": { "name": "github.com/microsoft/STL" }
    },
    {
      "commit": "4c0618b0e44f7ef027ebae05d2cc7812048f7c8f",
      "package": { "name": "github.com/ulfjack/ryu" }
    },
    {
      "commit": "5fe1940275d04432da841896bac0a66cc2375551",
      "package": { "name": "github.com/asmjit/asmjit" }
    },
    {
      "commit": "c9a9e5b10105ad850b6e4d1122c645c67767c341",
      "package": { "name": "github.com/openssl/openssl" }
    },
    {
      "commit": "da607da739fa6047df13e66a2af6b8bec7c2a498",
      "package": { "name": "github.com/madler/zlib" }
    },
    {
      "commit": "f454e231fe5006dd7ff8f4693fd2b8eb94333429",
      "package": { "name": "github.com/PCRE2Project/pcre2" }
    },
    {
      "commit": "f8745da6ff1ad1e7bab384bd1f9d742439278e99",
      "package": { "name": "github.com/facebook/zstd" }
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "jquery"
      },
      "version": "4.0.0"
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "jquery-migrate"
      },
      "version": "4.0.2"
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "tablesorter"
      },
      "version": "2.32"
    }
  ]
}

and I would like to focus on pcre2

   {
      "commit": "f454e231fe5006dd7ff8f4693fd2b8eb94333429",
      "package": { "name": "github.com/PCRE2Project/pcre2" }

where I believe commit f454e231fe5006dd7ff8f4693fd2b8eb94333429 tags pcre 10.47. When we run the query, we were expecting to get CVE-2026-86145, but we didn't. The report says that this has been fixed in pcre 10.48 and we run pcre 10.47, so we were expecting to get a notification from our integration with OSV.

To Reproduce
Steps to reproduce the behaviour:

1. Make a query towards https://api.osv.dev/v1/querybatch with the payload from above
2. See the response. The response does not report of CVE-2026-86145 among possible others. I believe CVE-2026-86145 should have been reported, but it wasn't. Please, correct me if I am mistaken.

Expected behaviour
I was expecting to get all the CVEs for which PCRE2 10.47 is vulnerable.

Thanks for looking in this and keep up the good work!

[Ly-Joey]

Hi @kikofernandez ,

Thank you for raising the issue!

We have looked into this record, the "introduced" commit 89296a3 linked to the pcre2-10.32 release is not present in the repository, so we couldn't enumerate the affected commit range properly (the "introduced" and "fixed" commits aren't connected).

We need to come up with a solution / fallback for these cases. Assuming unbounded "introduced" is probably not a good idea as it could lead to a lot of false positives.

[kikofernandez]

Hi @Ly-Joey,

Thanks a lot for looking into this so quickly, and for the clear explanation of what iss going wrong — that really helped us understand OSV's behaviour here.

I thought maybe I can brainstorm a little from the downstream/consumer side (we query OSV by commit in our CI), in case this can be an interesting idea, or something to throw away :)

Brainstorming

• The introduced commit 89296a3b3b6de2a58b4c7f2bb3d780a4f97cad39 is actually the target of the pcre2-10.32 release tag, and the commit we query, f454e231fe5006dd7ff8f4693fd2b8eb94333429, corresponds to pcre2-10.47.
• So even though the two endpoints are not connected in the commit graph, both of them do resolve to points in pcre2's linear release history (10.32 -> 10.47 -> fixed in 10.48).

An unbounded introduced might not be necessary here. When the commit-graph enumeration cannot connect the endpoints:

• would it be possible to fall back to comparing the release tags those commits point to, in version order, rather than defaulting to "affected from the beginning of time"?

In this case: 10.32 <= 10.47 < 10.48 which implies affected, while 10.00–10.31 stay correctly excluded. That would avoid the false negative we hit without opening the door to the false positives you (rightly) want to avoid.

This may only work cleanly when both endpoints map to tagged releases and the history is roughly linear — arbitrary mid-development commits or parallel maintenance branches would be quite tricky... But for the case of "released library, downstream pins a tagged release," anchoring on the release tags may be a safe fallback, or better than an unbounded lower bound.

Feel free to ignore this brainstorming session, it was something to think about,. I am sure the actual implementation has probably quite a few edge cases that I cannot even foresee :)

Either way, thanks for maintaining OSV — it has been working great for the Erlang/OTP team.