Data quality issue with CVE-2024-11477

[lorepirri]

The CVE ID
https://osv.dev/vulnerability/CVE-2024-11477

Describe the data quality issue observed

The record has an unresolved_ranges entry for the 7-Zip version range, but the CPE from the CISA ADP container (cpe:2.3:a:7-zip:7zip:*:*:*:*:*:*:*:*) is not preserved alongside it.

The source CVE5 record (https://cveawg.mitre.org/api/cve/CVE-2024-11477) has both a versions array and a cpes array in the CISA ADP container. The converter correctly reads versions and produces the unresolved_ranges entry with fixed: 24.07, but drops the cpes array.

Suggested changes to record

The unresolved_ranges entry should include the CPE, consistent with how CPE_STRING entries are handled for :o: CPEs (as seen in CVE-2019-20477/Fedora):

"unresolved_ranges": [{
  "source": "CPE_STRING",
  "cpes": ["cpe:2.3:a:7-zip:7zip:*:*:*:*:*:*:*:*"],
  "extracted_events": [{"introduced": "0"}, {"fixed": "24.07"}]
}]

Additional context

Comparing CVE-2019-20477 (PyYAML) reveals three converter behaviors:

1. :a: CPE with resolvable range → stored in affected[].ranges[].database_specific as CPE_RANGE.
2. :o: CPE with unresolvable range → stored in unresolved_ranges as CPE_STRING with CPE preserved.
3. :a: CPE with unresolvable range → stored in unresolved_ranges with CPE dropped.

The third case is the gap this record hits.

[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.

[jess-lowe]

Thanks for your interest in OSV's data quality!

This record is missing the CPE part of the unresolved ranges as it was converted and exported at an earlier iteration of these provenance improvements - technically this record shouldn't exist on OSV.dev as it has no real affected ranges that can be matched with an ecosystem/git repo.

We're adding CPE strings in database_specific for provenance understanding but due to the issues surrounding CPEs we don't intend for these to be used for matching, nor are we particularly inclined to support them.

Unfortunately, while 7zip is technically an open source project, it's distributed via zip files on the 7zip website/Source forge, which is somewhat difficult to programmatically determine from the original CVE record, and can't be allocated to a current ecosystem or registry that OSV supports.

[lorepirri]

Thanks for the detailed explanation @jess-lowe.

One follow-up: for the older records that were converted before the provenance improvements, is there a plan to reconvert them so the CPE strings are included in database_specific? Or will those records remain as-is?

For our use case, even without matching support, having the CPE present as provenance would let us correlate OSV records with NVD data for packages that don't map to a supported ecosystem.