We recognize the value external security researchers can bring to ConfigCat's security.
To get paid, you must have a Paypal or a bank account in your own name. It must accept transfers from Wise or Revolut. You will also need to send us an invoice and sign an agreements with us.
Please report issues through the Security Bug Report page after reading the Bug Bounty Program Terms.
Please note that you will get a reply after we have read, understood and carefully checked your report.
This might take several days, in some cases up to 2 weeks.
This document provides the terms for a bug bounty program for those individual researchers in the security community that provide contributions to manage the security of our systems in support of our users. Please note this is an interim program and is subject to modification, updates and cancellation as we develop our program. Until such time as we develop and publish our program, we require researchers to abide by the terms of this document. If you follow terms outlined below, we will not initiate or recommend legal or other action against you in response to your report.
You must act in good faith when investigating and reporting vulnerabilities to us. Acting in good faith includes:
Upholding the terms listed here. Failure to abide by the terms set forth here could result in non-payment and/or legal action if warranted.
Respect our users’ privacy. You should only interact with accounts that you own, or with explicit permission from the account holder. If you encounter user information that you do not have permission to access during the course of your research, you must:
No extortion. Any vulnerability reporting should be done with no conditions or strings attached. ConfigCat reserves the right to determine what we believe to be a reasonable payout for your efforts, and pay you based on our standards outlined below. Any attempt at extortion or ransom may result in legal action.
Do no harm. You should never leave a system in a more vulnerable state than you found it. This means you should not be conducting testing or other activities that degrades, damages, destroys, or harms information within our systems or otherwise impacts our users.
Certain services are not within the scope of this bug bounty program. If a service is not expressly identified as within scope, you should assume it is out of scope. If you require further clarification on what services are within the scope of this bug bounty program, you should ask our Team if you have any questions. Services that are not within the scope of this bug bounty program include, but are not limited to:
Any design or implementation issue that substantially affects the confidentiality or integrity of user data is likely to be in scope for this program. Common examples include:
Report qualifying vulnerabilities through our contact form.
Non-technical vulnerabilities such as DDoS, phishing, breaking and entering are not qualified for our bounty program.
The following is a list of bugs that typically don’t qualify for bug bounties, however, this list is not exhaustive or definitive.
We appreciate your time and effort in finding bugs. But we want quality reports, not just a high number of reports.
If you send too many false positives, invalid reports, or low-quality submissions, we may limit your submissions or even ban you from the program. We do this to keep the program useful for everyone.
When reporting issues, please go beyond just describing the problem. Provide possible solutions or a list of potential fixes. This helps ensure that at least one option is business-viable. Issues that cannot be reasonably fixed in a way that aligns with business needs are not considered true vulnerabilities, as their "fix" could introduce bigger problems than their existence.
Before you submit a report, please:
✅ Make sure the bug is real and reproducible.
✅ Check if it is out of scope.
✅ Provide clear steps, impact, and proof.
✅ Provide realistic possible solutions.
If we see repeated false positives or other low-quality reports from you, we may:
We are here to reward great work. Let's keep the program valuable for everyone! 🚀
We reserve the right to adjust payouts at our own discretion. But in general, we follow the following payout table to determine possible payout ranges for qualifying vulnerabilities, then use the severity of the vulnerability and other factors to determine a final payout amount. Please note, previous payment amount will not be considered precedent for future payouts, as the security impact of an issue may vary significantly based on the passage of time or development timelines.
The impact of exploiting the security risk | Min Payout | Max Payout |
---|---|---|
Unnoticed by the customers, a few hours of work for our team to resolve the situation. | $5 | $50 |
Likely unnoticed by the customer, but a significant resolution effort for our team. | $50 | $100 |
Noticeable customer impact. For example a service outage. | $50 | $500 |
Severe business and/or customer impact. For example, loss of user data. | $200 | $1000 |
Catastrophic impact. | $500 | $2000 |