Revoke

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 follow a fair responsible disclosure guideline.

We Do Not Revoke Correct Data

There are several reasons when and why we do not revoke information that has been 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 Limitation by Product Usage: The intentions of a software project and the given popularity of such do not influence the disclosure of vulnerabilities. As soon as a product is available (e.g. to purchase or for download) then it might be used and these users might be potential victims of attacks. They have the right to be informed about given risks.
  4. 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.
  5. 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.
  6. 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.
  7. CVE Dependency: If another CVE Numbering 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 an update or rejection of the CVE entry. As soon as this happened, we will update or revoke our vulnerability entry as well. We are not able to reject CVE entries that are maintained by other CNAs unless we are their superior CNA (e.g. Root-CNA).

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.

Mise à jour: 02/09/2024 par VulDB Documentation Team

Interested in the pricing of exploits?

See the underground prices here!