As a vulnerability database and official member of the CVE program it is our task to document vulnerabilities. More details help people to comprehend the inner workings of security issues and to understand the risk implications.

We Do Not Revoke Correct Data

There are several reasons when and why we do not revoke information that could be determined as correct:

  1. Public Information Stays Public: As soon as vulnerability details become public, it is the only reasonable decision to make these available to the defensive community as well. This is the reason why we do not revoke nor suppress vulnerability details. Otherwise only malicious actors could profit from exclusive information. This might also hold true for exploitation details as they could be helpful to deploy custom countermeasures (e.g. pattern-matching based filters).
  2. No Limitation by Attack Pre-Requisites: The level of pre-requisites necessary to approach and enforce an attack does not influence the existence of a vulnerability. If a high level or pre-requisites is given, such will be declared in the CVSS scoring alone. This helps users and administrators to understand the potential risk of exploitation.
  3. No Dependency on User Behavior: Whenever a vendor provides an official fix or a workaround, the exploitation of an issue remains rather limited. From then on it is up to the affected end-users and customers to decide whether they want to ignore or mitigate the documented risk. We cannot and will not depend a vulnerability disclosure on the intentions whether users are willing to establish countermeasures or not.
  4. Coverage of Products that are End-of-Life: Vendors and manufacturers might depublish their products, for example because they substitute them with a newer release or a company goes defunct. A product not being available anymore does not impact our basic approach to document a vulnerability. It only might influence the wording of our entries to reflect the current state of product availability (e.g. setting the field cna_eol properly). Depublishing a product does also not result in us revoking vulnerability entries as the product might be distributed otherwise or still in place maintained by existing users.
  5. Maintain Depublished Vulnerabilities: Vendors, researcher, or 3rd parties depublishing their vulnerability analysis does not influence the availability of our vulnerability entries in any way. The affected sources might be tagged as not available anymore which is true for our service and the CVE entries that we maintain. Under certain circumstances we are able to link to alternative sources or provide a cached version of the original source.
  6. CVE Dependency: If another CVE Numering Authority published a CVE record, we are obligated to process and add this data as well. If this data is incorrect, please contact the responsible entity and demand a rejection of the CVE entry. As soon as this happened, we will reject our vulnerability entry as well. We are not able to reject CVE entries that are maintained by other CNAs.

Correcting and Revoking False Data

If a vulnerability entry is a false-positive or contains wrong information, we will correct the data or revoke the entry. It is possible to dispute a vulnerability entry. The availability of a commit history helps VulDB users to understand the lifecycle of an entry.

Aktualisierung: 20.06.2024

Do you want to use VulDB in your project?

Use the official API to access entries easily!