CVE-2026-59083 not returned by /v1/query for affected package pkg:maven/org.apache.tomcat.embed/tomcat-embed-core@11.0.21

[metawave]

The record itself (GET /v1/vulns/CVE-2026-59083) correctly lists the affected range as 11.0.0-M1 through 11.0.23:

{
  "id": "CVE-2026-59083",
  "summary": "Apache Tomcat: Incorrect URL decoding in RewriteValve may allow security control bypass",
  ...
  "affected": [
    {"introduced": "11.0.0-M1"}, {"last_affected": "11.0.23"},
    ...
  ]
}

But querying by package+version does not return it:

POST /v1/query
{"package":{"purl":"pkg:maven/org.apache.tomcat.embed/tomcat-embed-core@11.0.21"}}

returns 10 other Tomcat CVEs affecting the same package/version (GHSA-2827-2mxx-j8pv and others), but not CVE-2026-59083, even though 11.0.21 falls squarely inside the record's own stated affected range.

Reproduced with osv-scanner (queries the same endpoint) and independently with trivy (own DB) — both miss this specific CVE for tomcat-embed-core@11.0.21 while correctly surfacing the other 10 Tomcat CVEs on the identical artifact.

Looks like an indexing/linking gap between the record and the package-version query index, rather than a data issue in the record itself. Happy to provide the full purl list / more repro details if useful.

[metawave]

Follow-up: this isn't isolated to tomcat-embed-core. I cross-checked against two independent Maven/npm projects (comparing Black Duck's SCA findings against /v1/query results for the exact same purl), and found the same record-exists-but-query-doesn't-return-it pattern is systemic:

Project	Real CVE IDs checked (excl. vendor-only advisory IDs)	Record exists but /v1/query misses it	Record doesn't exist at all
Project A (Maven)	55	52 (95%)	3
Project B (Maven + npm)	85	80 (94%)	5
Total	140	132 (94%)	8 (6%)

So in this sample, 94% of "CVE record exists in OSV but isn't returned by /v1/query for an affected package+version" — it's not a small edge case, it's the dominant failure mode for cross-tool CVE-matching discrepancies I was investigating.

It also isn't Maven-specific. Same pattern shows up on npm packages too, e.g.:

• pkg:npm/%40angular/compiler (a known CVE affecting the installed version doesn't come back from /v1/query)
• pkg:npm/micromatch
• pkg:npm/yarn

Other affected Maven packages beyond tomcat-embed-core in my sample: org.quartz-scheduler:quartz, org.springframework.boot:spring-boot-starter-aop, org.apache.pdfbox:fontbox, org.springframework.security:spring-security-web, io.netty:netty-transport-native-epoll, io.netty:netty-codec-http2, org.apache.cxf:cxf-rt-ws-policy, org.keycloak:keycloak-core, org.springframework.boot:spring-boot-starter-web, org.apache.tika:tika-core.

Happy to share the full CVE/purl list (140 rows) if that's useful for reproducing/debugging the indexing pipeline.

[metawave]

Root cause found, and it looks like a duplicate/regression of an already-diagnosed bug class rather than something new.

GET /v1/vulns/CVE-2026-59083 has affected[].package.ecosystem and .name both null — there is no proper Maven affected[].package entry at all. The real version-range data (11.0.0-M1 through 11.0.23) only exists under database_specific.unresolved_ranges (source: "AFFECTED_FIELD"), which /v1/query apparently doesn't consult for matching. That's exactly the mechanism @sonpoas described in #5979 for CVE-2026-57819 (org.apache.cxf:cxf-rt-frontend-jaxrs) — CVE v5 record has a well-formed packageName/collectionURL/version-range, but the converter drops it into database_specific instead of producing a proper ecosystem: Maven affected entry.

I checked this against 5 more of the 132 CVEs from my earlier comment (different packages: Quartz, two different Spring Framework CVEs, Apache PDFBox, Netty) — all 5 show the identical pattern: affected[].package.ecosystem: null with the real range parked in database_specific.unresolved_ranges. So this isn't specific to Tomcat, CXF, or any one CNA — it looks like a systemic gap in the CVE v5 → OSV conversion for Maven-sourced CVEs.

#5979 itself references #3582 ("CVE v5 converter should preserve collectionURL/packageName/affected version info"), which was closed as completed but apparently doesn't hold for these records — so this may be a regression rather than an open gap.

Given how many downstream tools (osv-scanner, Trivy, SonarQube SCA, and presumably others) build directly on /v1/query results, fixing the CVE v5 → Maven affected[].package conversion would likely resolve a meaningful chunk of the "known CVE not surfaced by scanner" reports across the ecosystem, not just this one record.

Happy to send the full list of ~140 affected CVE/purl pairs if that helps prioritize or test a fix.