Bug Bounty Bug Bounty Bug Bounty

🐞 What is bug bounty?

Bug bounty is an open competition to find vulnerabilities in a product. There are several approaches to testing services. The standard one – when the team's own testers check the service before its release. And the second, less common one – bug bounty. It is a competition where hackers and programmers are invited to find bugs and vulnerabilities in a service for a reward. It works roughly like this:

1. A company announces a competition to find issues and vulnerabilities in its project.
2. It announces approximate price ranges for different levels of vulnerabilities and bugs;
3. Testers, programmers and white-hat hackers look for issues in the product and submit them to the company;
4. The company rewards successfully found vulnerabilities, bugs and issues in its software;

👨‍💻 Why do we need it?

For us, bug bounty is an opportunity to make our products even better and to show that our services are reliable. Our project expands and scales every day, which requires constant debugging and monitoring of all processes. Users connected to the IT field often reach out to us and voluntarily point out various bugs. By systematizing these processes, we can reward everyone who helps us become better.

🏆 Rewards

It is quite difficult to define strict limits and reward amounts – since vulnerabilities and bugs can be of completely different nature and cause damage of varying severity to the service. However, we have tried to develop a scale that will let you roughly estimate your effort by its importance.

✅ A report is rewarded if the following requirements are met:

• Working PoC: Clear step-by-step reproduction instructions and proof of exploitation. Theoretical and hypothetical findings without a demonstration are not considered.
• Real impact on AvanChange: The vulnerability must affect our own systems/data. The reward amount is based on real impact, not on a CVSS vector score or a nominal “criticality”.
• Manual validation: The report is prepared and verified by a human, excluding AI scanners and LLM pentest pipelines.
• One vulnerability - one report. Do not combine several findings into one report and do not split one finding into several.
• First report only: The reward goes to the first person to submit a valid report; duplicates and already known/fixed issues are not paid.
• Safe testing: Test only on your own accounts and data. Prohibited: affecting other users, DoS/load testing, mass automated actions that degrade the service.
• Responsible disclosure: Do not publish any details until we confirm the fix has been deployed.
• Scope: AvanChange assets only. Third-party services, leaked/stealer-log credentials and dark-web dumps are out of the program scope.

In the case of fraud, the reward depends on how scalable the particular fraud method is, how easy it is to use, and the level of damage caused. The decision on the criticality level is made together with our developers. This may take some time, on average up to 2-4 weeks.

🚫 Exceptions

AvanChange does not pay a reward for:

• fraud that requires massive and simultaneous actions by a large number of users;
• slow brute-forcing using multiple accounts is outside the scope of the program;
• social engineering of AvanChange employees;
• disclosure of public user information;
• issues and vulnerabilities based on the version of the product in use, without demonstrating exploitation;
• zero-day error messages in TLS
• reports on insecure SSL/TLS ciphers without demonstrating exploitation;
• absence of SSL and other BCPs (best current practice);
• missing security mechanisms without demonstrating an exploit that could affect user data. For example, missing CSRF tokens, Clickjacking, etc.;
• Reflected download, same-site scripting and other attacks with questionable impact on the service's security;
• absence of CSP policies on the domain or insecure CSP configuration;
• XSS and CSRF, that require additional actions from the user. A reward is paid only if they affect sensitive user data and trigger immediately when the user navigates to a specially crafted page, without requiring any additional actions from the user;
• XSS that requires injecting or spoofing some header, for example, Host, User-Agent, Referer, Cookie, etc.
• Content spoofing, content injection or text injection without proven security impact;
• presence or absence of SPF and DKIM records;
• attacks that require physical access to the user's device;
• duplicates and vulnerabilities already known to or fixed by us;
• theoretical and hypothetical vulnerabilities without a working PoC and proven impact;
• leaked credentials, stealer logs, dark-web dumps and any findings on third-party (non-AvanChange) services;
• missing or misconfigured security headers and email records (HSTS, MTA-STS, cookie flags, etc.) without demonstrating exploitation;
• user/email enumeration, missing rate-limiting, verbose error messages - without proven security impact;
• findings on dev/staging/internal hosts and any non-production resources;
• best-practice recommendations without exploitation.

📊 Statistics

🏁 I want to participate – where do I start?

We have no strict requirements for bug bounty participants. Anyone can try their hand and get a reward for it! When you find vulnerabilities, please prepare a report document describing the vulnerabilities themselves and the methods of their exploitation. The report document should be sent to the E-mail: code@avanchange.com.