GCVE corrections to upstream data?

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.

It shows an affected record of:

{
  "product": "Firefox for",
  "vendor": "Mozilla",
  "versions": [
    {
      "lessThan": "Android",
      "status": "affected",
      "version": "unspecified",
      "versionType": "custom"
    }
  ]
}

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

2 Likes

Thanks for the feedback.

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.

1 Like

Great, thanks! It would be excellent news if they are willing to start accepting PRs there!

For tracking the issue open at CVElist/CVE Program

Maybe @zmanion has some good ideas.

1 Like

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.

1 Like

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.

3 Likes

What about modifications to the GCVE-0- records or something like that?

1 Like

This is indeed a potential strategy or even a dedicated GNA matching CVE id and all proposals are there and public. I like the idea.

1 Like

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

1 Like

Oh, I really like that idea!

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"
  },