Nothing is perfect. We are eager to improve to provide the best possible experience for our users. This is the reason why we have established an official bug bounty program. You may report security issues in our services and get rewards in return.
For the submission of new vulnerabilities into the vulnerability database not affecting our service please consult the submission policy.
If you have found a technical issue or a security vulnerability in one of our services we are happy to know about it. Just contact our support team which will handle the flaw as quickly as possible.
Please send a quick summary of your finding which covers:
- Affected component and/or URL
- Type of vulnerability (e.g. XSS, SQLi)
- How to exploit the issue
- Screenshot of the exploitation
- Your VulDB user to be upgraded (username / mail address)
- Your name if you want to be listed in the Hall of Fame on this site and/or the changelog
We will make a best effort to handle and process submissions as quickly as possible. Our response targets are:
- First response: within 2 business days
- Time to triage: within 4 business days
- Time to bounty: within 14 business days
- Time to resolution: depends on severity and complexity (usually before or with bounty delivery)
Please do not discuss nor share information about vulnerabilities or your submission outside of the bug bounty program without express consent from us.
If a report can be confirmed, is a security vulnerability, and has a certain increased severity we might provide one or multiple of the following rewards:
- Free commercial account extension for 12 months (equals a value of USD 2'388)
- Listed as bug reporter in the changelog
- Listed as member of the Hall of Fame
- Custom bug bounty medal on your VulDB user account
- Printed book and/or ebook by scip AG
- Certain highly critical issues might be rewarded with monetary compensation (e.g. remote code execution, SQLi, authentication bypass, broken access control)
All bug bounty submissions will be reviewed. The reward is based on the severity of the submission. Prerequisites (e.g. access vector, authentication, user interaction) and impact influence the rating of a vulnerability. The following table summarizes the usual ranges of the most common issues.
|Remote Code Execution||✔️||✔️|
|Cross Site Scripting||✔️||✔️|
|Server-Side Request Forgery||✔️||✔️|
|Direct Object Reference||✔️||✔️|
|Cross-Site Request Forgery||✔️||✔️|
Aggressive and Automated Testing
Automated (e.g. scans) and aggressive testing (e.g. flooding) might cause throttling, limitation, or even blacklisting of access possibilities. Therefore, we recommend manual testing or defensive optimization of automated requests.
Not all reports are eligible for rewards. There might be some limitations or rejects if you report one of the following:
- False-positives (e.g. Google dorks linking to vulnerability entries)
- Physical scenarios (e.g. fire, earthquake)
- Disclosure of products (e.g. generic banner, product names in links)
- Disclosure of public files (e.g. robots.txt, security.txt)
- Disclosure of generic path names (e.g. web root directory)
- Simple analysis of error codes (e.g. HTTP status codes, API response codes)
- Descriptive error messages (e.g. server errors, application erros, stack-traces)
- Optional HTTP security headers with theoretical impact only
- Optional mail security settings (e.g. SPF, DKIM, DMARC)
- Moderate SSL/TLS issues (e.g. test certificate validity, support of older versions for non-critical access, CAA settings)
- Bruteforce of forms (e.g. contact, signup, login)
- Flooding and exhaustion attacks against resources (denial of service)
- Self-XSS affecting only the attacking user
- Cross-Site Request Forgery (CSRF) for non-critical forms (e.g. search, logout)
- Revealing hidden information with CSS hacks
- Best practices (e.g. lifespan of user sessions, session invalidation after password changes, certificate pinning, cryptography strength)
- Issues affecting ressources by 3rd parties (e.g. internet service provider, payment provider, user client software)
We do not participate in negotiations about vulnerability submissions and rewards. Insistence, re-submits, and beg bounties will be ignored, might lead to a blacklisting, and an addition to the Hall of Shame.
Hall of Fame
The following users successfully contributed to our bug bounty program:
Do you want to use VulDB in your project?
Use the official API to access entries easily!