Bug Bounty
How to Report Vulnerabilities in our Services
Keypoints
How to Report Vulnerabilities in our Services
- If you have found a security vulnerability in one of our services, contact us immediately
- Please send a quick summary of your finding with technical details
- We will make a best effort to handle and process submissions as quickly as possible
- Do not discuss nor share information about vulnerabilities outside of the bug bounty program
- If a report can be confirmed, is a security vulnerability, and has a certain increased severity we might provide rewards
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.
Our bug bounty is fully compliant with security.txt as described in RFC 9116. You will find the current file at /.well-known/security.txt
Contact
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
If you are interested in the rewards, please also include the following information:
- 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
Response Targets
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)
We will not respond to basic misunderstanding of technologies, obvious false-positives, findings that are clearly defined as out-of-scope, and beg bounty requests. It is the task of the reporter to identify and eliminate these before submission. Resubmits of such will be blacklisted and the submitting party might be added to a Hall of Shame.
Disclosure Policy
Please do not discuss nor share information about vulnerabilities or your submission outside of the bug bounty program without express consent from us.
Rewards
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:
- Commercial account at VulDB for 12 months (equals a value of USD 2’388)
- Listed as bug reporter in the news
- Listed as member of the Hall of Fame
- 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)
Vulnerability Guidelines
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.
Vulnerability | Low | Medium | High | Critical |
---|---|---|---|---|
Remote Code Execution | ✔️ | ✔️ | ||
Privilege Escalation | ✔️ | ✔️ | ||
SQL injection | ✔️ | ✔️ | ||
Cross Site Scripting | ✔️ | ✔️ | ||
Server-Side Request Forgery | ✔️ | ✔️ | ||
Direct Object Reference | ✔️ | ✔️ | ||
Misconfiguration | ✔️ | ✔️ | ||
Cross-Site Request Forgery | ✔️ | ✔️ | ||
Open Redirect | ✔️ | ✔️ | ||
Information Disclosure | ✔️ | ✔️ |
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.
Limitations
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)
- User-specific issues (e.g. weak passwords, lifespan of passwords, credentials stuffing)
- 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)
Negotiations
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 people successfully contributed to our bug bounty program:
- 🏅 Ľuboš Guláň (2024)
- 🏅 Mohamed Elbadry (2022)
Thank you for your excellence!
Questions about this topic?
Our experts will get in contact with you!