GHSA-v5pm-xwqc-g5wc not matching Microsoft.OpenAPI@2.0.0

[Falco20019]

Current Behavior

GHSA-v5pm-xwqc-g5wc not matching Microsoft.OpenAPI@2.0.0

Steps to Reproduce

1. Add PackageReference onto Microsoft.OpenAPI@2.0.0
2. Export SBOM to DependencyTrack
3. Ensure GHSA-v5pm-xwqc-g5wc is known in DependencyTrack
4. Ensure Internal Analyzer is enabled
5. Observe it's not matched

Expected Behavior

GHSA-v5pm-xwqc-g5wc MUST match Microsoft.OpenAPI@2.0.0

DependencyTrack GHSA information:

Imported SBOM information:

Dependency-Track Version

4.x

Browser

Microsoft Edge

Checklist

• I have read and understand the contributing guidelines
• I have checked the existing issues for whether this defect was already reported

[nscuro]

What's the exact DT version you're on? Both 4.14.1 and 4.14.2 shipped fixes for NuGet version range support, e.g. #5958

[Falco20019]

I'm on 4.14.2

The minimum version in the vulnerability is 2.0.0-preview11 and according to semantic versioning 2.0.0 is newer than any pre-release. Also preview11 is sorted alphabetically while preview.11 would be sorted alphabetically first and then numerically second. It's hard to get all comparisons features correct as there are some traps.

[nscuro]

The version comparison correctly recognizes that, and we have tests that proof it:

dependency-track/src/test/java/org/dependencytrack/tasks/scanners/InternalAnalysisTaskPurlMatchingTest.java

Lines 37 to 38 in 72c6095

	Arguments.of("pkg:nuget/System.IO.Packaging", withRange().havingStartIncluding("8.0.0-preview.1.23110.8").havingEndIncluding("8.0.0"), MATCHES, "pkg:nuget/System.IO.Packaging@8.0.0"),
	Arguments.of("pkg:nuget/System.IO.Packaging", withRange().havingStartIncluding("8.0.0-preview.1.23110.8").havingEndIncluding("8.0.0"), DOES_NOT_MATCH, "pkg:nuget/System.IO.Packaging@8.0.1"),

The problem here appears to be casing in the PURL though. Note how both GitHub and OSV report Microsoft.OpenAPI to be vulnerable, but your component is Microsoft.OpenApi. The internal analyzer thus gets no hits when it performs lookups against the database using Microsoft.OpenApi.

According to the PURL spec, the name is case-sensitive: https://github.com/package-url/purl-spec/blob/main/docs/types/definitions/nuget-definition.md#name-definition

[Falco20019]

Then the GitHub advisory is broken. https://www.nuget.org/packages/Microsoft.OpenApi is the NuGet packet with the correct name. Thanks, I will let them know.

[AgentSFK]

I can confirm this issue and have identified the root cause: Dependency-Track's internal analyzer compares NuGet PURL package names case-sensitively, while NuGet package IDs are case-insensitive per specification.

Details:
The advisory GHSA-v5pm-xwqc-g5wc lists the package as Microsoft.OpenAPI (uppercase "API"). Both GitHub and OSV data arrive in DT with that spelling — the "Affected Components" tab of the vulnerability shows all version ranges correctly:

• pkg:nuget/Microsoft.OpenAPI (>=2.0.0-preview11|<=2.7.4) — GITHUB
• pkg:nuget/Microsoft.OpenAPI (>=3.0.0|<=3.5.3) — GITHUB
• pkg:nuget/Microsoft.OpenAPI (>=2.0.0-preview11|<2.7.5) — OSV
• pkg:nuget/Microsoft.OpenAPI (>=3.0.0|<3.5.4) — OSV

The canonical NuGet package ID however is Microsoft.OpenApi (lowercase "pi"), which is what SBOM generators emit. My Trivy-generated SBOM contains pkg:nuget/Microsoft.OpenApi@2.4.1 → no finding, despite 2.4.1 being well inside the affected range.

Minimal reproduction (two otherwise identical single-component CycloneDX BOMs):
"purl": "pkg:nuget/Microsoft.OpenApi@2.4.1" (canonical casing) → no finding
"purl": "pkg:nuget/Microsoft.OpenAPI@2.4.1" (advisory casing) → finding matched (GHSA-v5pm-xwqc-g5wc, alias CVE-2026-49451)

Regarding "the advisory is broken": Yes, the advisory casing diverges from the canonical package ID, and that should be reported upstream too. But fixing the advisory only fixes this one instance. Since NuGet package IDs are case-insensitive by spec (and the package-url spec also defines the name as case-insensitive for the nuget type), any future advisory or SBOM generator with divergent casing will silently produce false negatives again.

Suggested fix: Normalize case when matching pkg:nuget PURLs (e.g. lowercase both sides for the name comparison), analogous to how CPE matching was made case-insensitive in #5299 (v4.13.5).

I'm happy to provide the two reproduction BOMs if helpful.

[nscuro]

Thanks, Claude.

[Falco20019]

@nscuro Microsoft itself specifies in https://learn.microsoft.com/en-us/nuget/reference/nuspec#id that the package ID is case-insensitive. In package-url/purl-spec#226 there is a discussion (ongoing for 3 years) to fix it accordingly, but it never happened. So doing as Claude suggest should be the proper way of handling the PURL in this case.

I fixed the GHSA and now DT is also finding it, but this will only fix that one occurrence.