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.

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

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.

Maintain Depublished Products

Vendors and manufacturers might depublish their products, for example because they substitute it 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.

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. The availability of a commit history helps VulDB users to understand the lifecycle of an entry.