Submission Policy

📌 Article pinned by VulDB Support Team

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

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 and by submitting new vulnerability entries they agree to the Submission Policy.

Disclosure Timeline

Submitted vulnerabilities are stored in a queue and usually moderated within 2-5 business days. Processing is usually initiated within 2-12 hours. If a coordination with an external party is required (e.g. vendor or another CNA), 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, submitting users will be informed in in their online cockpit 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 code, 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 and embargoed until the vulnerability and the associated submit gets disclosed to the public.

If a vendor needs further assistance in handling a vulnerability which was submitted by a user, we will share the contact information (e.g. email) of the responsible user. It is a requirement that this user invests a reasonable effort to support the vendor regarding the disclosure.

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. The submitting user 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 their scope takes priority it might be necessary that the requested CVE handling must be transferred to them.

If the vendor disputes or rejects the issues, further negotiation with our Root-CNA (MITRE) might be required. Such external dependencies introduce 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 personal 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.

Embargo

Submissions, all its details and associated communication are confidential and embargoed. If a vulnerability is accepted the vulnerability details and the associated submission will become public. If a submission is rejected or of any malicious nature it remains in the embargo state and none of the associated details will be accessible to the public.

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 and ranks for submits.

Splits

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

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 agree with a vulnerability disclosure, they may contact us and file for a dispute. This dispute must contain a clear and complete rationale which will be quoted or paraphrased in the disclosure. Technical proofs help to establish such a dispute more quickly. If the dispute is reasonable, we will flag the entry as such. Data that could be determined as correct will not be revoked nor suppressed.

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 other CNAs.

Rejects

If a submission is not qualified as a new vulnerability it will be rejected. Every reject contains an explanation which is made available to the submitting user. Common reasons are spam, false-positive, and invalid data. Besides the official reject reason stored in the submit and the communication with the submitting user we do not provide additional details about the decision.

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.

Community Points

Users are awarded community points for submits. The amount of points depends on the quality of the initial submission and the resulting vulnerability entry. Collecting community points will increase the rank of an user.

Weak Submissions

If a submitting user is providing weak submissions which lead to merges or rejects, the priority of future submissions of said user might be decreased, further submissions might be limited temporarily or even permanently. Details about such a limitations are made available to affected users in the submission form.

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 smuggling duplicates.

Bug Bounty

VulDB does not pay bug bounties for vulnerability submissions nor submissions affecting non-VulDB products. Please refer to the VulDB Bug Bountry program otherwise.

更新済み: 2025年03月15日 キーワード: VulDB Documentation Team