I’m not sure if this is possible yet, or if it is intended for the future, but in the process of looking at some of the new Vendor/Product/CPE mapping stuff available at https://cpe.gcve.eu/ (which seems very well done!) I encountered a product record for Firefox For. Now if we look at where that comes from, we find GCVE - cpe:2.3🅰mozilla:firefox_for:*:*:*:*:*:*:*:* which indicates it is from CVE-2020-15647. If we look at the NVD record for this we can see it has a sensible configuration of cpe:2.3:a:mozilla:firefox running on cpe:2.3:o:google:android ; however, if we look at the upstream CVE5 record , we can see that it is incorrect and likely the source for this strange product entry within GCVE.
I guess I’m wondering if there is some way of correcting this on the GCVE side and if so how we would go about that? As far as I am aware there isn’t really a way of correcting the CVE5 json when it is incorrect other than asking CNAs to do it which they may or may not be willing to do
That’s actually a very good point. How to make a proposal for a CNA update. I see via the pull-request on the cvelistv5 repository but not sure if the CVE program will accept it. I might reach out to the CVE program to explain such case.
In the meantime, we introduced aliases which could at least solve the problem for the defenders to know all the products even the ones with typographic errors.
If you see anything else, let us know. Thanks again for your contributions.
And as far as using aliases goes, it does work for this specific case right now because there is only a single record with the typoed product so you could map it specifically to the corresponding firefox for android product, but it would lead to ambiguity in future if, for instance, another record intended for firefox for iOS made the same typo, and I’d like to figure out a way to be able to resolve those.
Hmm, that didn’t seem like a very promising reply, but then again I didn’t really expect the CVE program to put in any real effort here. It just seems a bit disappointing that we have a centralised authority with none of the benefits of a centralised authority (ie one simple, easy, to use place to go to propose edits that flow down to everyone consuming the data), and all of the drawbacks
Indeed, sometimes I feel like Don Quixote, especially when we ask for very minor improvements that are silently discarded.
On the positive side, during a workshop on the new functionalities in Vulnerability-Lookup, we will explore ways to receive contributions directly through Vulnerability-Lookup. This will allow CPE editors and Vulnerability-Lookup data to be shared between the two systems, ultimately expanding the dataset available in GCVE.
@cedric Should we register a special GNA for CVE proposal in the prefix around 65530 ? and then all the proposal received via GNA-1 is actually published as this alternative GNA? and the ID is actually the CVE-ID not changed.
First BCP proposal (still super draft), feedback more than welcome.
The following GNA has been created for testing:
{
"id": 65530,
"short_name": "GCVE-CVE-Extension",
"full_name": "GNA Dedicated to CVE Extension and Proposal - ID must be aligned with CVE ID reference",
"gcve_url": "https://discourse.ossbase.org/t/gcve-bcp-11-community-proposed-updates-to-existing-cve-records/1110",
"inserted_at": "2026-07-13T16:26:53Z",
"updated_at": "2026-07-13T16:30:07Z"
},