Rules and Guidelines

Getting Started

1. Register and create a Researcher account.
2. Immediately after registration, enable two-factor authentication (2FA) in your account settings.
3. Complete the onboarding process - the system collects data about your experience, interests, and the time available for research.
4. Complete identity verification - it is required to receive monetary rewards (see “User Verification”).
5. Read these Rules and Guidelines in full before submitting any vulnerability reports.

After registration, you will receive instructions on filling in your personal and contact details, submitting reports, tracking rewards, and receiving payouts for confirmed vulnerabilities.

User Verification

To receive monetary rewards, all researchers must complete identity verification:

1. Provide an electronic copy of your identity document (both sides).
2. Provide a photo that clearly shows your face next to the document.
3. After successful verification, the payout feature becomes available in your account.

The data provided during verification is processed to confirm your identity and make payouts in the manner and on the terms established by the Privacy Policy. The Operator does not transfer your data to third parties, except in cases provided for by the Privacy Policy and the legislation of the Republic of Kazakhstan, and is not responsible for incorrectly or inaccurately provided data.

Vulnerability Disclosure Policy

A vulnerability is a reproducible flaw in a system that can be intentionally used to compromise its integrity or confidentiality, or to cause a malfunction.

• Do not publicly disclose or share with third parties any information about a discovered vulnerability until you have received the explicit permission of the information system owner.
• If you follow the established Bug Bounty rules and act in good faith and within the approved scope of the program, the Operator will not take legal action regarding such research.
• Interact only with your own accounts or with the explicit permission of the account owner.

Rules of Participation

To participate in any program, you must act ethically, responsibly, and in accordance with these rules.

1. Do not disclose information about a discovered vulnerability until you have received the explicit permission of the information system owner (see “Vulnerability Disclosure Policy”).
2. Do not use threats of public disclosure of reports as a means of pressure - on moderators, the information system owner, or the platform - to influence a decision, speed up review, or increase the reward. Such behavior is treated as extortion and results in immediate sanctions, up to permanent account suspension.
3. Make every effort not to harm users or services - always act in good faith.
4. Use only your own accounts, phone numbers, and devices for research. Do not attempt to access other users’ accounts or data.
5. If during testing you accidentally gain access to personal data, immediately delete all related information and notify the platform team.
6. Take all reasonable measures to avoid breaches of confidentiality and service availability: unauthorized access to data, destruction of data, interruption or degradation of the service.
7. Provide a manual proof of concept (PoC) for each vulnerability (see “Report Requirements” and “Responsible Use of AI Tools”).
8. Communicate with all platform participants respectfully and professionally (see “Respectful Communication”).
9. The following actions are prohibited and will result in denial of payment and possible account sanctions:

• Physical interference with the operation of data centers or offices
• Social engineering targeting company employees
• Hacking the company’s infrastructure to gather material for a report
• Attempts to access other users’ accounts or data

Depending on the context and severity of the incident, consequences range from an official warning to temporary or permanent loss of privileges on the platform.

Respectful Communication

All researchers are expected to communicate respectfully and professionally with moderators, information system owners, and other platform participants. The moderation team works hard to review every report fairly and promptly. Please treat them accordingly.

Rude, aggressive, or disrespectful communication with moderators - regardless of your disagreement with a decision - is grounds for account sanctions. We expect a professional tone in every situation.

Private and Public Programs

Private programs are available by invitation only. All reports remain confidential. Researchers may not publicly discuss discovered vulnerabilities. It is prohibited to disclose the existence of a private program, your invitation to it, or any of its contents. Access to private programs is granted by invitation. Invitations are extended to researchers who have established themselves on the Platform; selection takes into account, but is not limited to, in particular:

• Verification - completed identity verification (a mandatory condition; see “User Verification”).
• Reputation - the researcher’s reputation on the Platform and position on the leaderboard.
• Points - points accumulated for accepted reports.
• Quality, not quantity - the share of accepted and substantive reports matters more than the total number of reports submitted; a large number of duplicate, “informational”, or rejected reports reduces the chances of an invitation.
• Behavior - compliance with the rules and program scope, respectful communication with moderators, and absence of violations (see “Rules of Participation” and “Respectful Communication”).

The Platform determines the researchers invited to private programs at its own discretion. An invitation to a private program is not guaranteed and may be revoked in the event of a violation of the Platform’s rules.

Public programs are available to all researchers on the platform and are an excellent way to develop skills and build reputation on the platform. Researchers may not publicly discuss discovered vulnerabilities.

Out-of-Scope Targets

When submitting a report, you select the vulnerability type. If there is no suitable type in the list, the “Other” or “Custom” category is available.

Before selecting the “Other” category, review the program description and make sure the affected target is within the approved scope (domains and vulnerability types).

If a vulnerability outside the domain scope is discovered accidentally during testing and is of high severity, you may report it, but a reward and points are not guaranteed; the report may also be rejected.

QazNet Programs - Special Rules

QazNet programs cover resources in the .kz domain zone and are implemented in support of the national “Cyber Shield 2” concept. Given the scale of the zone, these programs do not involve direct contractual relationships with all information system owners - reports are accepted in an open format, and the decision to accept a report and the reward amount remains with the information system owner. For this reason, response and payout times under the QazNet program may be long or absent.

Reports submitted under any QazNet program must meet the following requirements:

1. Specify the domain or confirmed ownership of the IP. If you submit an IP address without a domain name, you must indicate which resource or owner it belongs to and attach proof of ownership (e.g., reverse DNS, WHOIS). Reports with an IP address without confirmed ownership are not considered.
2. The research target must meet at least one of the following conditions: (a) a domain name in the .kz top-level zone; or (b) the resource is hosted in Kazakhstan (the server is physically located in KZ IP space). Reports on resources that do not meet these criteria are rejected regardless of the type or severity of the vulnerability.
3. Inactive and abandoned resources are not accepted. A resource is considered inactive if all of the following conditions are met at once: (a) the site has no active functionality (no forms, authentication, dynamic or user-generated content); (b) the page returns only a blank screen, a single line of text, a 403/503 error without content, or a default web-server page. If a researcher believes a resource is active despite these external signs, this must be justified in the report (e.g., by indicating active endpoints, API responses, or forms). In exceptional cases, at the moderator’s discretion, such reports may be accepted with the “Noted” status, without a reward.

Testing Rules

General Rules

Automated testing tools must not exceed 5 requests per second per target host and no more than 3 parallel threads at a time.

Avoid aggressive testing - you are testing a live production environment. Aggressive scans may trigger security systems and lead to your account, phone number, or IP address being blocked by the target.

Mobile Application Testing

When submitting vulnerabilities in mobile applications, describe all steps starting from the SSL pinning bypass. Reports that skip this step may be considered incomplete.

The following are not accepted for mobile applications:

• Reverse engineering or lack of binary obfuscation
• Lack of root/jailbreak detection
• Lack of SSL certificate pinning
• Missing security flags in native libraries
• Vulnerabilities that require malware, root, or jailbreak on the device to exploit
• Attacks requiring MITM or physical proximity to another person’s device (NFC, Bluetooth, Wi-Fi)

If you have test accounts ready for the application under test, provide them to the moderators - this speeds up moderation and reduces the load on the infrastructure.

Submitting Vulnerability Reports

1. Go to the “Programs” section and select a program. Read the program description carefully - it lists the in-scope domains and accepted vulnerability types.
2. Click “Submit Vulnerability.”
3. Attach all supporting materials. Complete evidence significantly increases the likelihood of a reward and points.
4. After submission, the report receives the “New” status.
5. You can withdraw a report via “My Reports” while it is in the “New” status - before it is reviewed by a moderator.

Report Requirements

Every valid report must contain:

• Proof of the vulnerability
• A description of the exploitation
• Complete step-by-step reproduction instructions

Incomplete, unclear, or poorly structured reports may be rejected without further review. The Operator and moderators reserve the right not to review reports in which the exploitation steps are provided only in attachments.

If you find an API documentation page (Swagger, OpenAPI, Postman collections, etc.) or another resource where a single finding automatically affects dozens of requests, submit one report for the entire finding rather than a separate report for each endpoint or request.

If several separate reports are submitted for a single finding, Tumar.One moderators and the information system owner’s moderators reserve the right to merge them into one; points and payment are awarded for the first correctly submitted report.

Images, video recordings, and scripts with the .py or .sh extension are accepted as proof of concept (PoC). HTML pages and other formats are not accepted as PoC: on their own, they do not confirm that a vulnerability was exploited. A report with a PoC in an unsupported format may be rejected.

Responsible Use of AI Tools

The use of GenAI tools and automation (scripts, fuzzers, scanners) to assist research is allowed under the following conditions:

• You must manually check and confirm each vulnerability before submitting.
• The report body must describe manual reproduction of the vulnerability - step by step, without references to “run the script.” A script may be attached as supplementary material (.py or .sh), but it does not replace the description of the manual steps.
• The moderator must be able to reproduce the vulnerability from the report description without running the attached script.
• Reports submitted without manual checking and verification, as well as reports without a step-by-step description, are subject to rejection.

Mass Submission Policy

If the same vulnerability is found on different domains within QazNet programs, the following procedure applies. Whether reports belong to the same finding is determined by the nature of the vulnerability - its class and vector - and not by the title or severity level specified by the researcher.

Mass submission of nearly identical reports (for example, 50 reports in a day for a single finding across different QazNet domains) creates noise and a significant load on the moderation team. In such cases, the first report is processed as usual (triage and scoring); each subsequent report for the same finding is also reviewed and moderated but, as a rule, receives a minimal score - for example, 1 point per report.

Systematic submission of repetitive, low-value reports, including for the purpose of artificially accumulating points, is classified as bad-faith use of the platform. In such cases, the Operator may take action against the account - from a warning to permanent restriction of access.

For applicable report-quality requirements, see “Report Requirements” and “Responsible Use of AI Tools.”

Report Statuses

Processing from submission to payout usually takes about 3 months but may take longer. Specific timelines depend on the program and the information system owner’s response speed and are not guaranteed. The Platform forwards reports to information system owners weekly, and response times may vary.

The SLA for the “New” → “Moderated” stage is about 2 weeks on average. Individual programs may specify a different SLA in their description; if no SLA is specified, the platform’s indicative value applies. The “Moderated” → “Sent to Owner” stage may take up to 2 weeks or longer. Further stages depend on the owner’s response and are not guaranteed.

Retest requests (“Retest”) must be answered within 2 weeks. After this period, the request is closed automatically. Both private and public programs may request a re-check.

Separately: if the owner accepted the report (the “Accepted” status) but the program does not provide a payout or no reward was assigned, the report remains in the “Accepted” status, with points awarded and no monetary reward.

Duplicate Confirmation

If your report is assigned the “Duplicate” status, you may be provided with the submission date of the original report as confirmation. By default, no other information about the original report is disclosed - including the report ID, its contents, and the nickname of the researcher who submitted it - however, it may be disclosed at the discretion of the program moderators.

Final Severity Determination

A researcher may specify their own severity assessment in the report, but it is taken into account only as input. The severity decision is final after moderation. Appeals against severity decisions and report decisions are not available. A researcher may leave a comment in the report with additional technical justification; the moderation team reviews it at its discretion but is not obligated to change the assessment.

Rewards and Payouts

To receive monetary rewards, you must first complete identity verification on the platform (see “User Verification”).

The reward amount is determined by the program terms. Programs with monetary rewards publish payout ranges in their description; programs without monetary rewards provide points only.

In public programs, the information system owner may decline a submitted report; in that case, points and/or a monetary reward may not be awarded.

After a reward is confirmed, the report is assigned the “Need signature” status. At this stage, the researcher must sign a contract and/or an Act of Work Performed / Services Rendered provided by the Operator. Researchers who are not citizens of the Republic of Kazakhstan may be required to execute additional agreements. The platform terms are accepted by the researcher upon registration or login by clicking the checkbox “By continuing, you acknowledge that you have read, understood and agreed to the Privacy and Personal Data Processing Policy and Public Offer” - this action is recognized as acceptance of the Public Offer Agreement for the provision of access to the web resource.

If a payout is assigned the “Rejected” status due to a technical error on the service side, the Operator begins fixing it and informs the user. For any questions, the user can contact support: email info@tumar.one, Telegram bot @TumarOneSupportBot.

Payouts are made to a bank card. For international transfers (outside the Republic of Kazakhstan), you must provide the SWIFT code of the recipient bank; the transfer currency is US dollars (USD). The recipient bank must not be on sanctions lists (OFAC and other applicable ones). In some cases, payment via PayPal is possible. The payment and contact details you provide are processed to make payouts in the manner established by the Privacy Policy. The Operator is not responsible for incorrectly provided details or data.

Payout Statuses

Taxes and the Act of Work Performed / Services Rendered

The Operator acts as the researcher’s tax agent: it independently withholds and remits tax on rewards in accordance with the legislation of the Republic of Kazakhstan. On this basis, all researchers must sign an Act of Work Performed / Services Rendered; foreign nationals additionally sign the relevant document. This is a requirement of the tax authorities.

All amounts shown on the platform are Gross - that is, before the deduction of taxes and other mandatory payments. The researcher actually receives the amount net of such deductions, so the final payout may be less than the amount shown in the report.

This arrangement relieves the researcher of concerns about legalizing income earned through bug bounty. The Platform does not transfer the researcher’s personal data to third parties, except in cases provided for by the Privacy Policy and applicable law.

Vulnerabilities That Are Not Accepted

The following vulnerability types are not accepted by default across all programs. Individual program descriptions may specify exceptions or additional restrictions - be sure to review the program terms before submitting a report.

• IDOR - considered only in cases of high severity (determined by our specialist upon confirmation of the vulnerability)
• Any XSS other than Stored XSS
• Stored XSS - considered depending on the significance of the web resource
• Clickjacking
• Insecure Redirect URI
• Directory Listing Enabled - considered only when critical data is disclosed (passwords, backups, etc.)
• Sensitive Data Exposure - considered only when critical data is discovered
• Enabled debug mode - considered only if critical data is disclosed
• CSRF - considered only for critical functionality
• Admin panel disclosure - considered only when account takeover or access to critical information is possible
• User Enumeration - considered only when critical data is disclosed
• Security Misconfiguration - considered only with evidence that the threat can be realized
• Denial of Service (DoS)
• Spam
• Social engineering targeting employees, contractors, or customers
• Any physical attempts to gain access to the property and/or data centers of the information system owner
• Reports based solely on automated scanner output - a manual proof of concept is required
• Errors in third-party software - considered only with proven impact on the target
• Missing security headers that do not directly lead to a vulnerability
• SSL/TLS configuration weaknesses without proven exploitability
• Vulnerabilities affecting only outdated or unsupported browsers/platforms
• Password and account recovery policies (e.g., reset-link expiration, password complexity)
• Outdated DNS records pointing to systems not owned by the information system owner
• DMARC Policy Not Configured

Vulnerability Types by Severity Level for Public Programs

Points are awarded by vulnerability severity level as follows:

• Low severity - from 0 to 30 points
• Medium severity - from 31 to 60 points
• High severity - from 61 to 100 points

High severity:

• Remote Code Execution (RCE)
• SQL Injection
• XML External Entity Injection (XXE)
• Server-Side Template Injection (SSTI)
• Account Takeover
• Authentication Bypass
• Privilege Escalation

Medium severity:

• Server-Side Request Forgery (SSRF)
• 2FA Bypass
• Using Default Credentials
• Path Traversal
• Local File Inclusion (LFI)
• Unsafe File Upload
• Subdomain Takeover
• DBMS Misconfiguration
• File Extension Filter Bypass
• Insecure Data Storage
• Race Condition

Low severity:

• Brute Force
• Zone Transfer
• Mail Server Misconfiguration
• Insecure Data Transport
• Using Components with Known Vulnerabilities
• Parameter Pollution
• CRLF Injection
• Weak Registration Implementation
• Lack of Password Confirmation
• No Size Limit (File Upload)
• Misconfigured DNS
• HTTP and HTTPS Available
• Insecure CAPTCHA
• Potentially Unsafe HTTP Method Enabled

The severity level depends on the potential impact of the discovered vulnerability. For this reason, security analysts evaluate each report individually. In addition, vulnerability assessments differ across programs, so before submitting a report be sure to review the program description and follow its rules.

Leaderboard and Seasons

The Tumar.One researcher leaderboard is updated at the start of each season. A researcher’s position is determined by the total number of points earned in the previous season. The top researchers of the year make the annual Top 10 and are invited on stage at the KazHackStan conference.

Contacts and Support

For any questions, you can contact us by email at info@tumar.one or via Telegram support: @TumarOneSupportBot.