Submission Policy

VulDB is a public Vulnerability Database which collects, analyzes, documents, and discloses security vulnerabilities in electronic devices and computer systems.

Vulnerability Reporting

Users are able to submit new vulnerabilities online which shall be disclosed and/or added to the database. By accessing our services they agree to the general Terms and Use.

Disclosure Timeline

Submitted vulnerabilities are stored in a queue and moderated within 2-5 business days. Processing is usually handled within 2-12 hours. If a coordination with an external party is required (e.g. vendor), then the processing might take longer than 7 days.

Quality Control

The moderation team aims to provide a certain level of quality regarding entries and data. This quality control might require more time for communication and validation. If the default disclosure timeline cannot be held, the submitting user will be informed about the ongoing processing steps or the new timeline.

A submission must contain the vendor name, product name, affected versions, and vulnerability class. Providing as much information as possible helps the moderation team to validate new submissions faster and with a higher level of accuracy. Detailed summaries, exploit details, screenshots, and videos are highly appreciated.

If the moderation team is not able to verify the true existence of a submitted vulnerability, the moderation will be postponed or rejected until valid details are made available by the submitting user or a 3rd party.

Coordinated and Responsible Disclosure

It is the task of the submitter to approach the vendor early to align a coordinated and responsible disclosure. VulDB does not provide a service to handle and track vendor communication. As soon as vulnerability details become public, it is our obligation to process them. No matter if and how a product maintainer was involved in the disclosure process. Under certain circumstances we do inform the vendor before the disclosure to give them a possibility to react early. This whole communication is confidential until the vulnerability gets disclosed to the public.

CVE Assignment

If a submission does not have a CVE assigned already, it aligns with the general CNA Rules and is not in scope of another CNA, we assign a new CVE the moment we moderate the submission. You will receive confirmation of the submission and the assigned CVE.

If the affected software is in scope of another CNA, we have to contact them first to coordinate further processing. If the vendor disputes or rejects the issues, further negotiation with our Root-CNA (MITRE) might be required. This external dependency introduces delays of unknown extent.

Communication

All communication regarding a new submission happens between the submitting user and the moderation team. The current status of the submission process is shared with the submitting user in their online cockpit. Registered users will receive an email to their linked account as soon as the moderation has happened. It will contain the moderation decision and further links.

Accepts

If a submission is qualified as a new vulnerability, it will be accepted. A new entry will be created based on the submission.

Reporter

The submitting user will be listed as submitter and/or researching party that identified the vulnerability. Users are able to ask to suppress this information on the service. Registered users can do this in their settings. Registered users gain community points for submits.

Splits

If a submission contains multiple vulnerabilities the submission will be split into their respective entries. Every split is handled as separate submission.

Merges

If a submission could be identified as a duplicate of an existing entry, the data from the submission will be merged into the existing entry. The reporting user will be listed as contributor and as commiter to the entry. Registered users gain community points for commits.

Disputes

If a 3rd party does not aggree with a vulnerability disclosure, they may contact us and file for a dispute. This dispute must contain a clear and complete rationale. Technical proofs help to establish such a dispute more quickly. If the dispute is reasonable, we will flag the entry as such. And if we are the CNA responsible for issuing the associated CVE the CVE entry will tagged as a dispute as well. We are not able to dispute CVEs issued by otheer CNAs.

Rejects

If a submission is not qualified as a new vulnerability it will be rejected. Every reject contains an explanation and is made available to the submitting user. Common reasons are spam, false-positive, and invalid data. If an entry gets published which is a false-positive, it will be flagged as such and our assigned CVEs will be revoked. We are not able to reject CVEs issued by other CNAs.

Bug Bounty

VulDB does not provide a bug bounty for submissions affecting non-VulDB products. Please refer to the VulDB Bug Bountry program otherwise.

Blacklisting

Users abusing the submission capabilities will be blacklisted from submitting further items. Extended abuse might lead to disabling the entire account. This includes but is not limited to flooding, missing details, provoking false-positives or duplicates.

Are you interested in using VulDB?

Download the whitepaper to learn more about our service!