RuStore is an official Russian app store for Android devices. Find everything you need: from banks and marketplaces to entertainment apps and games.
Rewards are paid to individual entrepreneurs and self-employed persons
Program description

Supported languages:

  • English
  • Russian

Scope of the Bug Bounty program:

Domains:

rustore.ru, www.rustore.ru, api.rustore.ru, admin-backapi.rustore.ru, admin.rustore.ru, apps.rustore.ru, backapi.rustore.ru, back.rustore.ru, console.rustore.ru, dev.rustore.ru, pay-backapi.rustore.ru, static.rustore.ru, upload.rustore.ru

Testing Rules:

Due to the high volume of invalid and automatically generated reports, please attach a screenshot or screen recording, as well as a curl/http request necessary to reproduce the problem, to every report. The attached materials must clearly demonstrate the vulnerability and how to reproduce it.
Reports showing signs of automated generation may be rejected unless they include a screenshot or screen recording confirming that the vulnerability was manually verified and is reproducible.
Reports concerning vulnerabilities on *.rustore.ru domains may be accepted without a reward or for informational purposes if the vulnerability affects development services. We do not accept or reward vulnerabilities found in applications published on RuStore.
When testing, it is recommended to limit scanning tools to 10 requests per second.
When testing RCE, SQLi, LFI, LFR, or SSTI, use only the minimum necessary POC to confirm the vulnerability (sleep, reading /etc/passwd, hostname).
If you wish to go beyond the minimum POC, including to test for privilege escalation, first submit a report describing the vulnerability and the results obtained so far. In a comment to the report, specify exactly what you want to test, which commands or actions you plan to use, and what result you expect. Continue testing only after receiving permission from the RuStore team.
Without prior permission, do not execute commands or perform actions that could compromise the confidentiality, integrity, or availability of the service, its data, or internal files. Violating this rule may result in the report being rejected or the reward being denied.
Vulnerability testing must be performed only on accounts you own.

We consider reports informational if:

  • The report was submitted by a current employee of the RuStore or a former employee who left the company less than one year ago;
  • The vulnerability is found in a demo environment, on a domain used for training, or in a related application.

We do not accept or review:

  • Reports generated by AI, vulnerability scanners, or other automated tools without a screenshot or video demonstrating the vulnerability and the steps required to reproduce it;
  • Disclosure of information that is not confidential, for example, the version of a product;
  • Disclosure of information about a user that is public, for example, a user's nickname;
  • Bug reports based on the version of a product/protocol (e.g. TLS version);
  • Bug reports about a missing security mechanism/current best practice (e.g. missing - CSRF token, framing/clickjacking protection);
  • We do not accept disclosures of internal hostnames, IP addresses, or sourcemaps;
  • Messages about published and unpublished SPF and DMARC policies;
  • Cross-site request forgery leading to logout (logout CSRF);
  • Vulnerabilities in partner products or services, unless company users/accounts are directly affected;
  • Security of rooted, jailbroken, or otherwise modified devices and applications;
  • Vulnerabilities in outdated OS and applications;
  • Attacks in which the user independently granted permissions to a malicious application;
  • Ability to reverse engineer an application, or the lack of binary protection;
  • MitM and local attacks;
  • Open redirects, insufficient session validation, handling cookies after logout, etc. are not accepted unless additional vectors are defined (e.g., the ability to steal a session token via a remote vector for open redirects);
  • Open redirection vulnerabilities are accepted only if a security impact is identified, such as the possibility of stealing an authorization token;
  • Injecting unformatted text, audio, images, or video into a server response outside of the user interface (for example, into JSON data or an error message), unless doing so replaces the user interface, changes the behavior of the user interface, or results in other negative consequences;
  • Same site scripting, reflected downloads, and similar attacks with questionable impact;
  • CSP-related bug reports;
  • IDN homograph attacks;
  • XSPA (scanning the IP addresses/ports of external networks);
  • Excel CSV formula injection;
  • Scripting in PDF documents;
  • Attacks that require full access to a local account, browser profile, or physical access to the device;
  • Attacks based on scenarios where a vulnerability in a third-party site or application is required as a prerequisite and is not demonstrated;
  • Theoretical attacks without proof of feasibility;
  • Denial of service (DoS) vulnerabilities, for example - sending a large volume of requests or data (flooding);
  • Ability to send a large number of messages;
  • Ability to send spam or a malware file (for example, registration or password recovery spam);
  • Disclosure of information through external links not controlled by the company (for example, Google dorking of private protected areas of robots.txt);
  • Disclosure of unused or properly restricted JS API keys;
  • Disclosure of keys or use of an external map service or error tracing service - App Tracer, Sentry, DaData and others;
  • Ability to perform an action not available through the user interface and without identified security risks;
  • Vulnerabilities associated with the use of phishing and other social engineering techniques;
  • Disclosure of /metrics, /status, htaccess or similar without a demonstrated information security threat (for example, disclosure of private API methods, tokens);
  • Blind SSRF vulnerabilities without demonstrating a threat to the service's information security in the report;
  • EXIF metadata in images;
  • SSRF vulnerabilities that involve sending requests via rentgen*.smailru.net, snipster.*.go.mail.ru, mpr*.m.smailru.net, kbt-sand-node*.m.smailru.net, rs-proxy*.i.smailru.net, proxy.oneme.ru or other proxies specifically designed to protect against SSRF;
  • Vulnerabilities that disclose only user accounts but not passwords or other personal data (for example, user enumeration).

General Information

RuStore Security Team responds to a new report within 3 business days.
Rewards for reported vulnerabilities are assigned within 10 business days.
If the reward evaluation takes longer than 10 business days, the researcher will be informed additionally.
Public 0-day/1-day vulnerabilities may be considered duplicates for several weeks after a vulnerability is published if our team knows about the vulnerability from open sources and we are working to eliminate or fix it.

Disclosure Policy

Publication or disclosure of report details without prior approval from RuStore Information Security is strictly prohibited.
We reserve the right to decline any request for public disclosure of a report.

Bounty Rules:

The Bug Bounty program rewards only those vulnerabilities that were previously unknown to the RuStore Security Team and are fully reproducible.
The bounty amounts shown in the description are for reference only. The applicability and amount of a bounty may depend on the severity of the problem, novelty, likelihood of use, environment, and/or other factors.
The types of vulnerabilities eligible for bounties are listed in the "Rewards" section at the end of the rules for the Bug Bounty program rules.
Any vulnerabilities not listed in the "Rewards" section are paid for at the discretion of the program owner.
RuStore Security Team makes a bounty decision for each report individually.
The maximum reward amount is calculated for the Server-Side vulnerability scenario that does not require brute-forcing identifiers and user interaction.

Rewards for 3rd party solutions used by VK

VK services may use solutions developed or maintained by a third-party company. Unfortunately, in such cases we cannot influence the timeline of analysis, the nature of the fix, or the reward decision made by the third-party vendor. As a result, the maximum reward for a vulnerability in a third-party vendor's product that we cannot fully fix without their involvement will be no more than 20% of the vulnerability category's value. If the vendor has a Bug Bounty program or a Security contact, you must first report the vulnerability to the vendor's security team.

Rewards:

VulnerabilitiesMaximum Bounty    
Remote code execution (RCE)3 600 000 ₽
Server-side Injections (SQLi or an alternative)2 400 000 ₽
Read local file content (LFR, RFI, XXE) without restrictions (jail/chroot/other file type restrictions)2 400 000 ₽
RCE in the Dev infrastructure / isolated or virtualized process1 200 000 ₽
Read local file content (LFR, RFI, XXE) in the Dev infrastructure / isolated or virtualized process240 000 ₽
Non-blind SSRF (with the ability to read the response text), except for dedicated proxies1 200 000 ₽
Blind SSRF, except for dedicated proxies120 000 ₽
Server-side vulnerability involving disclosure (e.g. memory leaks / IDORs) of critical or highly sensitive application data9 000 - 900 000 ₽ 
Server-side vulnerability involving disclosure (e.g. memory leaks / IDORs) of protected personal data or sensitive client information720 000 ₽ 
Server-side vulnerability involving disclosure (e.g. memory leaks / IDORs) of sensitive application or infrastructure data / organizational role privilege escalation720 000 ₽ 
Admin/support authentication bypass720 000 ₽
Blind XSS in the admin/support interface360 000 ₽
Cross Site Scripting (XSS)0 ‑ 60 000 ₽
Cross-Site Request Forgery (СSRF)0 ‑ 60 000 ₽ 
Subdomain takeover is considered under the same severity/conditions as cross-site request forgery (CSRF).
SSRF vulnerabilities are paid for only when demonstrating a threat to the service's information security.
Self-XSS, XSS specific to non-common browsers (e.g. IE), blocked CSPs and other vectors without proven script execution are generally accepted without reward.
Detailed error output, local installation path, phpinfo() output, performance counters, etc. are not considered confidential; such reports are usually accepted without reward. Reports about disclosure of software versions are not accepted.

Rules for AI Agents

We prohibit any AI agents from searching for vulnerabilities under this Bug Bounty program
Launched November 15, 2022
Edited August 12, 12:06
Program format
Vulnerabilities
Reward for vulnerabilities
up to ₽3.6M
Top hackers
Overall ranking
The ranking is still empty