CVE-2026-68497 not detected: OSV alias present, but no GHSA or alias assertion imported

[davidraimond]

Hello,

I am investigating what appears to be a missing vulnerability detection in Dependency-Track 5.1.1 and would like to understand whether the observed behavior is expected.

Environment:

• Dependency-Track 5.1.1
• Vulnerability sources enabled:
  • NVD
  • GitHub Advisories
  • OSV

Affected component:

• com.fasterxml.jackson.core:jackson-databind

Affected vulnerability:

• CVE-2026-68497

What I observed:

1. CVE-2026-68497 is present in the Dependency-Track database:

   SELECT "ID","VULNID","SOURCE"
   FROM "VULNERABILITY"
   WHERE "VULNID"='CVE-2026-68497';

   Result:
   ID = 506090
   SOURCE = NVD

2. The public OSV record explicitly lists the alias:

   GHSA-q4xh-88c3-wmh7

   https://osv.dev/vulnerability/CVE-2026-68497

3. I executed a manual mirror for all configured sources:

   • NVD
   • GitHub Advisories
   • OSV

   The mirror tasks completed successfully.

4. However, the alias does not appear in Dependency-Track:

   SELECT *
   FROM "VULNERABILITY"
   WHERE "VULNID"='GHSA-q4xh-88c3-wmh7';

   Result: 0 rows

5. The alias is also not present in:

   VULNERABILITY_ALIAS_ASSERTION

   Example:

   SELECT *
   FROM "VULNERABILITY_ALIAS_ASSERTION"
   WHERE "ALIAS_ID"='GHSA-q4xh-88c3-wmh7';

   Result: 0 rows

6. VULNERABILITY_ALIAS_ASSERTION contains more than 130,000 records, so aliases are generally being imported correctly.

7. As a consequence, Dependency-Track does not report this vulnerability for jackson-databind, while JFrog Xray does.

8. Additionally, the GitHub Advisory URL associated with this alias returns HTTP 404:

   GHSA-q4xh-88c3-wmh7

My questions are:

• Is Dependency-Track expected to ingest aliases exposed by the OSV dataset?
• Is the absence of GHSA-q4xh-88c3-wmh7 from both VULNERABILITY and VULNERABILITY_ALIAS_ASSERTION expected?
• Does Dependency-Track consume the OSV CVE conversion data that exposes this alias?
• Could this explain why CVE-2026-68497 is not matched against jackson-databind?
• Is this expected behavior, a limitation of the current OSV integration, or potentially an ingestion issue?

Thank you for your help and clarification.

[davidraimond]

Hello,
The 404 error disappeared this morning, and detection by DT is now working. Was a change made ?
Regards.

[nscuro]

We can't push changes on our end that would affect user deployments. Perhaps upstream data got corrected?