VulDB is a public Vulnerability Database which collects, analyzes, documents, and discloses security vulnerabilities in electronic devices and computer systems.
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.
Submitted vulnerabilities are stored in a queue and moderated within 2-5 business days. Processing is usually handled within 2-12 hours.
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 new timeline.
Providing as much information in a submission 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 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.
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 MITRE might be required. This external dependency introduces delays of unknown extent.
All communication regarding a new submission happens between the submitting user and the moderation team. 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.
If a submission is qualified as a new vulnerability, it will be accepted. A new entry will be created based on the submission.
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.
If a submission contains multiple vulnerabilities the submission will be split into their respective entries. Every split is handled as separate submission.
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.
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.
VulDB does not provide a bug bounty for submissions affecting non-VulDB products. Please refer to the VulDB Bug Bountry program otherwise.
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.
Might our Artificial Intelligence support you?
Check our Alexa App!