Does anyone know how to report errors to https://db.gcve.eu/?
-
Does anyone know how to report errors to https://db.gcve.eu/? Just their
info@mail? I looked up CVE-2026-6042 and CVE-2026-40200 there because I was annoyed that the NVD database (which #Buildroot uses for automated vulnerability checks) still didn't have them correctly labeled with the CPE (so automated tools can't identify the package is vulnerable).
Result: CVE-2026-40200 is correctly labeled (good!), while CVE-2026-6042 is not (different vendor/product). Mistakes happen, an organization that's trying to run as serious vulnerability DB really needs to provide an obvious "report errors here" mail address (or other means, but really… mail). #CVE #GCVE
-
Does anyone know how to report errors to https://db.gcve.eu/? Just their
info@mail? I looked up CVE-2026-6042 and CVE-2026-40200 there because I was annoyed that the NVD database (which #Buildroot uses for automated vulnerability checks) still didn't have them correctly labeled with the CPE (so automated tools can't identify the package is vulnerable).
Result: CVE-2026-40200 is correctly labeled (good!), while CVE-2026-6042 is not (different vendor/product). Mistakes happen, an organization that's trying to run as serious vulnerability DB really needs to provide an obvious "report errors here" mail address (or other means, but really… mail). I think there is a confusion between the messenger (GCVE database which is correlating more than 70 sources) and the source of the CVE records.
The two CVEs mentioned are coming from the official cvelistv5 source. We (GCVE) don't change the records from the different sources. The origin is the actual CVE program database.
The contact email is in the GCVE about page -> https://db.gcve.eu/about
You can also put comments on the records on the https://vulnerability.circl.lu/ which is also synced to the DB GCVE.
We feel your pain with incorrect data from the sources. Ideas are more than welcome.
-
I think there is a confusion between the messenger (GCVE database which is correlating more than 70 sources) and the source of the CVE records.
The two CVEs mentioned are coming from the official cvelistv5 source. We (GCVE) don't change the records from the different sources. The origin is the actual CVE program database.
The contact email is in the GCVE about page -> https://db.gcve.eu/about
You can also put comments on the records on the https://vulnerability.circl.lu/ which is also synced to the DB GCVE.
We feel your pain with incorrect data from the sources. Ideas are more than welcome.
@adulau@infosec.exchange @gcve@social.circl.lu
I think there is a confusion between the messenger (GCVE database which is correlating more than 70 sources) and the source of the CVE records.
Maybe. I thought it's intended as an alternative to e.g. NVD (especially given somewhat recent political developments), to get machine-readable vulnerability information. Is that wrong? If my understanding is correct, ensuring accurate information is a necessary part of the task, aggregate or not. A system that produces lots of false negatives (the issue at hand, not finding the issue by CPE) creates a false sense of complacency, a system that produces a lot of false positives tends to be ignored eventually.
The contact email is in the GCVE about page -> https://db.gcve.eu/about
Do you mean theinfo@address? It's listed as a general contact address, which I'd usually expect that to go to a front desk, not bug handling. Maybe I'm thinking too complicated, but in any case lack of clarity is my point.
We feel your pain with incorrect data from the sources. Ideas are more than welcome.
If GCVE doesn't have the resources to handle error reports (possibly forward them), a clear link on the vulnerability listing would already help. Something like "Report an error" which would then indicate where to report an error for the relevant source (without digging through a maze of documents).
For people like me who are looking at this stuff as part of volunteer work, minimizing friction of reporting is critical. I have only so much time and energy to spend. If it looks like reports aren't wanted anyway (the GCVE FAQ sadly does), or reporting is too much trouble, it's likely I'll drop it and focus on things where my effort feels more appreciated (and maybe grumble about it on Fedi). -
@adulau@infosec.exchange @gcve@social.circl.lu
I think there is a confusion between the messenger (GCVE database which is correlating more than 70 sources) and the source of the CVE records.
Maybe. I thought it's intended as an alternative to e.g. NVD (especially given somewhat recent political developments), to get machine-readable vulnerability information. Is that wrong? If my understanding is correct, ensuring accurate information is a necessary part of the task, aggregate or not. A system that produces lots of false negatives (the issue at hand, not finding the issue by CPE) creates a false sense of complacency, a system that produces a lot of false positives tends to be ignored eventually. The contact email is in the GCVE about page -> https://db.gcve.eu/about
Do you mean theinfo@address? It's listed as a general contact address, which I'd usually expect that to go to a front desk, not bug handling. Maybe I'm thinking too complicated, but in any case lack of clarity is my point. We feel your pain with incorrect data from the sources. Ideas are more than welcome.
If GCVE doesn't have the resources to handle error reports (possibly forward them), a clear link on the vulnerability listing would already help. Something like "Report an error" which would then indicate where to report an error for the relevant source (without digging through a maze of documents).
For people like me who are looking at this stuff as part of volunteer work, minimizing friction of reporting is critical. I have only so much time and energy to spend. If it looks like reports aren't wanted anyway (the GCVE FAQ sadly does), or reporting is too much trouble, it's likely I'll drop it and focus on things where my effort feels more appreciated (and maybe grumble about it on Fedi).@adulau@infosec.exchange @gcve@social.circl.lu For context: #Buildroot has tools to list known vulnerabilities for packages, currently based on NVD data (via https://github.com/fkie-cad/nvd-json-data-feeds).
I noticed it's missing a bunch of vulnerabilities (e.g. CVE-2026-40200, CVE-2026-6042 in musl libc) because the NVD data is missing CPE match information. At the time the CVEs were listed as "Awaiting Analysis", now "Deferred", so I assume it's not going to be added any time soon, if ever (generally the CPE match is present for vulnerabilities in "Analyzed" status). Looking at the GCVE listings was an attempt to find another, hopefully better, source, because an automated check that misses so many vulnerabilities is not going to be very useful.
Today @Bubu@chaos.social pointed me at a similar example: CVE-2025-6020 (note the year), a "high" level vulnerability in linux-pam, which is also marked as "Deferred" in NVD. So we really could use a better source.
We'd need one we can download (rather than query individual packages one by one) without excessive load, but solving that is another matter, first we need a suitable source at all. -
@adulau@infosec.exchange @gcve@social.circl.lu For context: #Buildroot has tools to list known vulnerabilities for packages, currently based on NVD data (via https://github.com/fkie-cad/nvd-json-data-feeds).
I noticed it's missing a bunch of vulnerabilities (e.g. CVE-2026-40200, CVE-2026-6042 in musl libc) because the NVD data is missing CPE match information. At the time the CVEs were listed as "Awaiting Analysis", now "Deferred", so I assume it's not going to be added any time soon, if ever (generally the CPE match is present for vulnerabilities in "Analyzed" status). Looking at the GCVE listings was an attempt to find another, hopefully better, source, because an automated check that misses so many vulnerabilities is not going to be very useful.
Today @Bubu@chaos.social pointed me at a similar example: CVE-2025-6020 (note the year), a "high" level vulnerability in linux-pam, which is also marked as "Deferred" in NVD. So we really could use a better source.
We'd need one we can download (rather than query individual packages one by one) without excessive load, but solving that is another matter, first we need a suitable source at all.https://vulnerability.circl.lu/dumps/ contains the full dump of all the sources. I feel your pain but we are trying to provide at minima the correlation among the different sources. We don’t actually modify the source but if you see a way to actually get proposal in an automatic way and extend it via GCVE records. I’m interested.
-
It’s indeed a problem and we are working on a cpe editor at GCVE to propose links to vulnerabilities towards vendor, product, version. And people can query that for correcting potential wrong attribution to vendor, product.
https://github.com/gcve-eu/cpe-editor
We plan to release it online in the next weeks.
-
R relay@relay.infosec.exchange shared this topic
