MAX

When analyzing the application, we recommend using virtual numbers and avoiding identifier enumeration, as any accounts suspected of malicious behavior are automatically blocked and cannot be unblocked.

It is recommended to limit all scanning tools to 4 requests per second.

When testing RCE, SQLi, LFI, LFR, SSTI it is allowed to use only MINIMALLY possible POC for proof (sleep, accessing /etc/passwd, curl). Privilege escalation testing must be submitted as a separate report, including a reference to the original submission.

Vulnerability testing should only be performed on accounts you own.

We consider bug reports as informational if:

The disclosure of information regarding compromised accounts belonging to external users of the service is prohibited.
The vulnerability is identified in a service independently hosted by the user (Mail.Ru\VK Cloud hosting network, hosting of gaming team resources, hosting of student or laboratory work for educational projects, etc.).

We do not accept or review:

Cross-site WebSocket hijacking;
Reports describing the ability to send and verify OTP codes;
Reports showing enumeration through incremental (integer) identifiers (adding to contacts, retrieving profile information, creating a dialog, and other actions), if access to the user's profile is allowed by privacy settings;
Bug reports from vulnerability scanners and other automated tools;
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) without demonstrating the actual presence of a vulnerability;
Bug reports about a missing security mechanism/current best practice (e.g. missing - CSRF token, framing/clickjacking protection) without demonstrating an actual impact on the security of users or the system;
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 Mail.Ru or VK.com users/accounts are directly affected;
Security of rooted, jailbroken, or otherwise modified devices 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 Mail.Ru or VK.com (for example, Google dorking of private protected areas of robots.txt);
Disclosure of unused or properly restricted JS API keys (for example, an API key for an external map service);
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, rs-proxy*.i.smailru.net or other proxies specifically designed to protect against SSRF;
Vulnerabilities that disclose only user accounts but not passwords or other personal data.

General Information

VK 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.

0-day/1-day vulnerabilities may be considered duplicates for several weeks after public disclosure if they are already known to the security team and are being addressed.

Disclosure Policy

Publication or disclosure of report details without prior approval from VK Information Security is strictly prohibited.

We reserve the right to decline any request for public disclosure of a report.

Bounty Pass Loyalty Program

You can learn more about the loyalty program for bug hunters at the following address.

Bounty rules:

The Bug Bounty program rewards only those vulnerabilities that were not previously known to VK Security Team.

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.

VK 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:

Vulnerabilities	Maximum bounty
Access to specific user's prviate messages*	5 000 000 ₽
Access to the real-time location of certain users*	2 000 000 ₽
Access to the phone book of certain users*	1 000 000 ₽
Violation of the role model in a channel/chat*	1 000 000 ₽
Access control violation when sending, editing, and deleting messages*	1 000 000 ₽
De-anonymization of the channel owner*	500 000 ₽
De-anonymization of channel subscribers*	250 000 ₽
Remote code execution (RCE)	2 400 000 ₽
Server-side Injections (SQLi or an alternative)	1 600 000 ₽
Read local file content (LFR, RFI, XXE) without restrictions (jail/chroot/other file type restrictions)	1 600 000 ₽
RCE in the Dev infrastructure / isolated or virtualized process	800 000 ₽
Read local file content (LFR, RFI, XXE) in the Dev infrastructure / isolated or virtualized process	160 000 ₽
Non-blind SSRF (with the ability to read the response text), except for dedicated proxies	800 000 ₽
Blind SSRF, except for dedicated proxies	160 000 ₽
Server-side vulnerability involving disclosure (e.g. memory leaks / IDORs) of protected personal data or sensitive client information	600 000 ₽
Server-side vulnerability involving disclosure (e.g. memory leaks / IDORs) of sensitive application or infrastructure data / organizational role privilege escalation	600 000 ₽
Admin/support authentication bypass	450 000 ₽
Blind XSS in the admin/support interface	350 000 ₽
User privilege escalation	250 000 ₽
Cross-site scripting (XSS)	30 000 ‑ 100 000 ₽

*Via Server-Side vulnerability

SSRF's are paid for only when demonstrate demonstrating a threat to the service's information security in the report.

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. Subdomain takeovers are considered under the same severity/conditions as cross-site request forgery (CSRF).

Detailed error output, local installation path, phpinfo() output, performance counters, etc. are not considered confidential; such messages are usually accepted without payment of a bounty. Messages about disclosure of software versions are not accepted.

Launched July 1, 11:22

Edited July 23, 14:14

Program format

Vulnerabilities

Reward for vulnerabilities

up to ₽5M

Top hackers

Score