EN

MyReviews

|Not enough reviews
Company: Craftum
MyReviews is a popular Russian service for automating the collection, monitoring, and management of customer reviews. It helps businesses track their online reputation, gather feedback, and improve their search engine rankings.
Rewards are paid to individual entrepreneurs and self-employed persons
Program description

1. Allowed languages

  • Russian;
  • English.

2. Scope

The program includes only the following resources:
 - myreviews.ru;
 - myreviews.dev;
 - subdomains *.myreviews.dev.
If an asset is not listed above, it is not part of the program. A domain appearing in source code, a CSP, DNS records, historical data, or a third-party integration does not bring it into scope.
The latest REST API documentation is available at https://myreviews.ru/api-docs.
The documentation can help you understand an endpoint's purpose, request format, and authentication requirements. However, whether an endpoint is present in or absent from the documentation does not, by itself, prove that a vulnerability exists. We require a demonstrated security impact.

3. What We Are Looking For

The program focuses on three areas.

Payment Bypass

Please submit a report if you are able to:
  • activate or renew a paid plan without making the required payment;
  • obtain a paid feature, quota, or limit without paying for it;
  • actually use a paid feature beyond the limits of your current plan.
Client-side changes, a payment link showing an unusual amount, a technical status, or an API record do not qualify as a payment bypass unless you actually receive the paid service or feature.

Parser Limit Bypass

Please submit a report if you are able to:
  • obtain parsing results beyond your plan or quota;
  • successfully complete a parsing operation while bypassing account restrictions;
  • use the free plan to obtain results from review platforms that are not included in that plan. The free plan currently supports Yandex only.
The creation of a task, a changed counter or status, or a 200 OK response does not demonstrate a bypass unless the resulting data or functionality is actually available to the user.

Обход ограничений автоответов

Auto-Reply Limit Bypass

Please submit a report if you are able to:
  • generate or send auto-replies beyond your plan or quota;
  • send a reply on behalf of another account or organization without its authorization.
Changes to a draft, template, counter, status, or user interface do not qualify as a vulnerability unless an auto-reply is actually generated or sent.
 

4. Critical Findings

Although the program's main focus is described above, we will also consider a critical vulnerability if it allows an attacker to:
  • take over another user's account or act on behalf of the account owner;
  • obtain valid authentication credentials;
  • access a significant volume of non-public, sensitive user data;
  • execute code or gain control over MyReviews infrastructure;
  • gain unauthorized access to data or permissions across multiple accounts.
These reports are reviewed on a case-by-case basis. A vulnerability class, CVE identifier, or high CVSS score does not, by itself, make a report critical. The report must demonstrate real-world impact.

5. How to Demonstrate a Vulnerability

We require a reproducible scenario and evidence of the actual result of exploitation.
The following do not qualify as sufficient evidence:
  • an assumption that the issue could be developed into a more serious attack;
  • data changed only in the user interface;
  • an unusual API response with no user-accessible result;
  • a misconfigured security control without a working exploit;
  • a theoretical attack chain without a complete proof of concept.
Use your own test accounts and the minimum number of requests and objects necessary for testing.

What We Consider Authentication Credentials

  • a password or password equivalent;
  • a password hash;
  • a valid session token, access token, or refresh token;
  • an API key;
  • an account recovery token or code.
An email address, UUID, numeric ID, internal name, status, or other technical metadata is not considered an authentication credential unless it independently allows someone to sign in to an account, access non-public data, or act on behalf of a user.

6. What We Do Not Accept

If the demonstrated impact does not fall under Section 3 or Section 4, the report will be closed as Out of Scope. The vulnerability class or CVSS score does not change this.
In particular, we do not accept:
  • software versions, headers, stack traces, internal hostnames, IP addresses, paths, or diagnostic messages;
  • CORS, CSP, CSRF, SameSite, X-Frame-Options, Secure, HttpOnly, or similar configuration issues without a working exploit;
  • open redirects, HTTP OPTIONS/TRACE, missing security headers, or other hardening observations;
  • reports based solely on a software version or CVE;
  • theoretical scenarios or issues in unreachable legacy code;
  • missing CAPTCHA, SMS verification, or rate limiting;
  • weak password policies or user enumeration;
  • long token lifetimes without a way to obtain and use another user's token;
  • logout CSRF or observations about stateless JWTs without access to another user's account;
  • registering with an unverified email address and signing in to an account you created yourself;
  • brute-force attacks or credential stuffing;
  • spam or abuse of public forms;
  • DoS/DDoS, connection exhaustion, or resource exhaustion;
  • self-XSS or XSS that works only within your own account;
  • attacks that require control over the victim's device, browser, or local network;
  • DNS, DMARC, SPF, DKIM, or DNSSEC observations;
  • IDN homograph attacks, Broken Link Hijacking, or Domain Hijacking without an impact described in Section 3 or Section 4;
  • issues in third-party services that have no direct impact on MyReviews.
XSS, CSRF, SSRF, IDOR, injection, race conditions, and other well-known vulnerability classes are not automatically in scope. What matters is the demonstrated impact described in Section 3 or Section 4, not the vulnerability class itself.

7. MyReviews-Specific Information

This section explains how the product works and does not expand the program's scope.

Public Organization and Widget Data

MyReviews provides public data for organization profiles and widgets embedded on customer websites. Accessing this data without authentication, with another user's JWT, or through a sequential ID is not, by itself, an IDOR vulnerability.
This applies in particular to the following APIs:
  • GET /v1/firm/view?id=<id> с любым значением demo;
  • GET /v1/widget/get-firm/...;
  • GET /v1/widget/get-reviews/...;
  • other endpoints that return data for a public organization profile or widget.
In this context, public or technical data includes:
  • an organizations name, address, image, website, and description;
  • UUIDs, numeric IDs, parent_id, and object types;
  • ratings, review counts, public review text, links, avatars, and photographs;
  • connected review platforms, dates, statuses, and aggregate counters;
  • public widget, QR code, or profile configuration;
  • setting flags, provided they do not disclose recipients, tokens, authentication credentials, or notification content;
  • isPaid, active, and similar status values that do not allow a paid or restricted action to be performed.
A false response from GET /v1/firm/access means that the user does not have permission to perform account management actions. It does not make the organization's public profile confidential.
Do not enumerate identifiers at scale. A minimal proof of concept using your own test objects is sufficient.

Reviews and Widgets

Review text, links, avatars, photographs, and metadata collected from public review platforms are not considered confidential.
The existence of a public review-submission endpoint or feedback form is not, by itself, a vulnerability.
Test review creation only on organizations that you own and use for testing. Do not post even a single test review, payload, or message such as test XSS or test CSRF to a real customer's profile without prior approval. Such reviews become public and are visible to users.
The number of widgets per organization is not limited. Creating multiple widgets is an intended feature of the service.

Companies, Quotas, and Plans

Creating a company record beyond a displayed limit, using a demo or free plan, or producing a negative counter does not, by itself, demonstrate a payment bypass.
You must show that the additional company actually received a paid feature, completed a restricted operation, or obtained a resource without payment.
An inactive record, technical status, service record, or running process with no user-accessible result does not qualify as a payment bypass.

Parsers

A server-side request to an allowed external review platform is an expected part of the parsing process.
Paid plans currently provide access to the same set of review platforms. The free plan supports Yandex only.
We accept parser-related reports only if they demonstrate a quota bypass or a critical impact described in Section 4.
An allowlist bypass that demonstrates only a blind callback to an external URL you control is out of scope.

Auto-Replies

You must demonstrate that an auto-reply was actually generated or sent beyond the applicable plan limit, or that a reply was sent on behalf of another account without authorization.
Changes to a draft, template, counter, status, or user interface without generating or sending a reply are out of scope.

SSRF

Blind SSRF, an external out-of-band callback, or the ability to reach an internal network is not sufficient on its own.
An SSRF report may be accepted as a critical finding only if it safely demonstrates access to sensitive internal data, a trusted endpoint, a metadata service, or another independently critical impact.
To test internal reachability safely, use only 192.168.4.72:8000.
Do not scan internal address ranges, metadata endpoints, ports, or services without prior written approval.

8. Safe Testing

Use only:
  • accounts you own;
  • accounts belonging to users who have explicitly authorized testing;
  • test accounts provided by MyReviews.
In most cases, two of your own test accounts and a small number of your own objects are sufficient for a proof of concept. If you need more, contact us before continuing.
Please stop testing as soon as you have confirmed the impact.
Without prior approval, you must not:
  • access accounts, data, or resources belonging to other users;
  • enumerate IDs, email addresses, usernames, companies, or other objects at scale;
  • send requests, messages, emails, reviews, or files at scale;
  • post test reviews, payloads, or references to vulnerabilities on profiles belonging to other organizations;
  • perform load testing or any action that could cause a DoS/DDoS condition;
  • use social engineering or phishing;
  • attack employees, customers, or partners;
  • upload malware, spyware, large files, or other dangerous files;
  • modify, delete, or replace server-side files, except for files belonging to your own test accounts.
If you discover an arbitrary file-read issue, you may read only /etc/ufw/user6.rules.
Obtain prior written approval before performing any other file-related action.

9. Report Requirements

Please include:
  • what happened and why it is a security issue;
  • the impact described in Section 3 or Section 4 that you demonstrated;
  • the affected asset and endpoint;
  • minimal reproduction steps;
  • requests and responses with secrets redacted;
  • the IDs of the test accounts and objects you used;
  • the date and time of testing;
  • screenshots, videos, or other supporting evidence;
  • remediation recommendations.
Do not include active tokens, passwords, keys, or personal data in clear text. Redact them in the report, screenshots, and videos.
If demonstrating the impact would require interacting with another user's data, MyReviews infrastructure, or service availability, contact the program team before proceeding.

10. Severity and Rewards

We first determine whether a report is in scope. We then assess its severity and reward amount.
We consider:
  • the demonstrated impact;
  • the affected data, features, and permissions;
  • the prerequisites and complexity of exploitation;
  • whether user interaction is required;
  • the number of affected users and resources;
  • the financial and infrastructure risk.
The maximum reward is RUB 50,000 before tax.
Zero-day and one-day vulnerabilities are reviewed individually if they meet the requirements of Section 3 or Section 4.

11. Duplicates

A reward is issued for the first report that contains enough information to reproduce and remediate a previously unknown vulnerability.
A report is considered a duplicate if, before receiving it, we already had another report, internal audit finding, or internal task containing sufficient information about the same root cause.
A different endpoint, a new exploitation technique, or a more detailed proof of concept is not considered a separate vulnerability if addressing it requires fixing the same root cause.
Duplicate reports are not eligible for rewards.

12. How to Request Additional Testing Time

  1. Register your own test accounts.
  2. Send the registration email address and a link to your verified Standoff 365 profile to bugbounty@myreviews.ru.
  3. After reviewing the information, the program team may add extra paid-plan testing time to your account.
Launched July 10, 10:59
Edited Yesterday, 06:19
Program format
Vulnerabilities
Reward for vulnerabilities
up to ₽50K
Excl. tax
Top hackers
Overall ranking
The ranking is still empty