Kuper is a delivery service from shops and restaurants for any occasion.
Kuper delivers fresh food, delicious ready-made food, medicines, cosmetics, flowers, household goods and beloved pets and much more in 20 minutes.
Today, 8 million items from 230 grocery chains, almost 1,300 non-food stores, 30 pharmacy chains and more than 38 thousand restaurants are available to customers. Kuperoperates in 360 cities.
Program description

Program rules

Kuper is one of the largest online services for the delivery of groceries and goods. We are happy to cooperate with independent cybersecurity researchers!
You need a Kuper account to conduct research. We do not provide test accounts, environments, or any other special access.

Research scope

Objectives

  1. Kuper
  1. Kuper for buisness
  1. Kuper Restaurants
  1. Other resources at *.kuper.ru
  • Except for cpa.kuper.ru (this is a third-party solution).

Vulnerabilities accepted for review and analysis

We are primarily interested in critical server-side vulnerabilities. The following types of vulnerabilities will be accepted for review and analysis and rewarded:
• Insecure authentication/authorization, session management.
• Authorization bypass and account hijacking.
• Business logic vulnerabilities (including fraud schemes related to system flaws).
• Leaks of sensitive information to third-party services.
• XSS and CSRF affecting sensitive data (a PoC is required).
• IDOR, privilege escalation, and other access control vulnerabilities.
• Disclosure of sensitive information or personal data.
• Injections (SQL, XML, LDAP, and so on).
• Insecure deserialization.
• SSRF.
• RCE.
• Open redirects are accepted only with a definite security impact, such as the possibility of an authorization token theft.
We may also accept vulnerabilities other than those on this list.

Vulnerabilities not accepted for review and analysis

• Bugs that are not related to security (technical bugs in applications or processes).
• Credential stuffing, or the use of leaked credentials to log in to various systems (except for account compromise that may have negative consequences; in this case, a PoC is required).
• Clickjacking.
• Social engineering techniques (including fraud related to social engineering).
• Hypothetical attacks without proof of their feasibility.
• Automatically generated scanner reports.
• Reports on published and unpublished SPF and DMARC policies.
• Cross-site request forgery resulting in logout (logout CSRF).
• Lack of advanced security measures in mobile apps (SSL pinning, root/jailbreak detection, obfuscation, and so on).
• Possibility of application reverse engineering or lack of binary protection.
• Same-site scripting, reflected downloads, and similar attacks with questionable impact.
• Attacks where a vulnerability in a third-party website or application is required as a prerequisite and its exploitation is not demonstrated.
• Blind SSRF without a security impact detailed in the report (DNS pingback is not sufficient).
• IDN homograph attacks.
• XSPA (IP address/port scanning of external networks).
• Excel and CSV formula injections.
• Scripting in PDF documents.

Vulnerabilities accepted for review and analysis but not eligible for rewards

• XSS, CSRF, and CORS misconfigurations with no actual security impact.
• SSRF with no access to the internal infrastructure.
• Use of components with known vulnerabilities without an actual attack vector or impact.
• Violation of SSL/TLS best practices without proof of exploitability.
• Missing security headers, cookie flags, and so on.
• Vulnerabilities affecting outdated browsers, plugins, and platforms.
• Content spoofing.
• Disclosure of non-sensitive information with no actual security impact (such as software versions or detailed error messages).
• Vulnerabilities in third-party software, except for insecure configurations.
• MITM attacks or attacks that require physical access to a user's device.
• Open redirects are accepted only with a definite security impact, such as the possibility of an authorization token theft.
• Vulnerabilities that require superuser permissions or a specially modified device.
• Possibility of sending a large number of messages (both email and SMS).

We consider reports on the following as informative:

• Disclosure of information about compromised user accounts of SberMarket services.
For these vulnerabilities, rewards are paid only if there is an impact on the systems.

Participation rules

  1. Use the least possible evidence of exploitability.
  2. Use your own accounts for testing.
  3. When searching for vulnerabilities, use the HTTP header X-Bug-Bounty: username.
  4. Do not disclose vulnerability information without written permission of the Kuper security team.
  5. Reports on 0-day vulnerabilities may be treated as duplicates within 2 weeks after the public disclosure of the vulnerability.
  6. The Kuper security team reserves the right to refuse public disclosure of vulnerability information.
  7. Do not tamper with user accounts without their owners' permission.
  8. Do not use detected vulnerabilities for personal purposes.
  9. When using automated security scanners, make sure they make no more than 10 requests per second to a single host (including all concurrent streams and all scanners running simultaneously).

RCE testing rules

When testing for remote code execution (RCE) vulnerabilities, researchers must adhere to the following rules.
Only the following actions are allowed on the server:
• Execute the ifconfig (ipconfig), hostname, whoami, id commands.
• Read the contents of the files /etc/passwd and /proc/sys/kernel/hostname (drive:/boot.ini, drive:/install.ini).
• Create an empty file in the directory of the current user.

Report requirements

A vulnerability report must contain a description of a vulnerability or a chain of related vulnerabilities, including the following:
• Brief description
• Details
• Steps to reproduce
• Recommendations for remediation
We will appreciate it if the report also includes the following:
• Vulnerability type
• Severity analysis
• A proof of exploit (PoE), such as screenshots or videos.
• Code demonstrating exploitability (PoC).

Reward

A reward is paid if the report meets the following conditions:
• The triager can fully reproduce the vulnerability on their own.
• The report is the first report accepted on this vulnerability.
• The Kuper security team was unaware of the vulnerability before the report.

Rewards

VulnerabilityReward, RUB.
Remote code execution (RCE)190 000 ‑ 400 000 ₽
SQL Injection (SQLi)100 000 ‑ 300 000 ₽
SSRF except for blind SSRF*75 000 ‑ 190 000 ₽
Blind SSRF*25 000 ‑ 75 000 ₽
Insecure authentication/authorization, session management25 000 ‑ 175 000 ₽
Cross Site Scripting (XSS)25 000 ‑ 175 000 ₽
Cross-Site Request Forgery (СSRF)25 000 ‑ 75 000 ₽
Local files access and others (LFR, RFI, XXE)25 000 ‑ 75 000 ₽
IDOR resulting in leakage of critical or highly sensitive information100 000 ‑ 190 000 ₽
IDOR resulting in leakage of protected personal data or confidential client information (depending on the amount of leaked data)50 000 ‑ 200 000 ₽
Open Redirect with a definite security impact, such as the possibility of an authorization token theft.10 000 ‑ 100 000 ₽
Fraud schemes and business logic vulnerabilities25 000 ‑ 250 000 ₽
Other confirmed vulnerabilitiesзависит от критичности
 
A vulnerability's severity level is ultimately decided by the Kuper security team. We use our own internal evaluation system, which is based on a number of criteria, to determine vulnerability severity and reward amounts.
If you have any questions, email us at bug-hunters@kuper.ru.
Launched December 26, 2024
Edited January 14, 07:45
Program format
Vulnerabilities
Reward for vulnerabilities
up to ₽400K
Top hackers
Overall ranking
Score
@64t
1.5K
Program statistics
₽190,000
Paid in total
₽63,333
Average payment
₽190,000
Paid in the last 90 days
7
Valid reports
28
Submitted reports
Description
Vulnerabilities
Ranking
Versions