[{"id":3771979,"new_policy":"## Program scope\n\nThis Vulnerability Disclosure Program applies only to the identification and reporting of technical security issues affecting the company’s services.\n\n## Cases not eligible for a reward\n\nNo bounty will be paid, and such activity may lead to a negative response, if any of the following is identified:\n\n- Social engineering attempts targeting company personnel.\n- Attempts to access accounts, data, or information belonging to other users, as well as any post-exploitation activity that is not strictly necessary to demonstrate the existence of the issue.\n- Denial-of-service, request flooding, or any other resource exhaustion activity. When using automated scanners, testing must stay within 5 requests per second (300 requests per minute) per target host across all tools and threads combined, with no more than 5 concurrent requests at any moment.\n\nTesting must be performed only with accounts, phone numbers, and other assets that belong to the researcher. Accessing third-party accounts or confidential data is not allowed. When testing contact forms, support channels, or similar features, the message subject must include `Test`, and the HackerOne email alias should be used.\n\n## Issues that are out of scope\n\nSecurity investigations will not be opened for the following:\n\n- Alerts or messages generated by automated scanners or other tools when there is no clear proof of concept and no demonstrated impact.\n- Reports based only on software or protocol versions, without evidence of actual exploitability or practical security impact.\n- Reports that only point to the absence of a security control or deviation from best practice, such as a missing CSRF token, without showing a real negative consequence.\n- Self-XSS.\n- Framing.\n- Social engineering.\n- Clickjacking.\n- SPF, DKIM, or DMARC issues.\n- Man-in-the-middle scenarios.\n- Vulnerabilities affecting partner products or third-party services that do not directly compromise the security of the company’s own services.\n- Infrastructure-level findings, including:\n  - Server-side configuration issues such as open ports or supported TLS versions.\n  - SSL/TLS certificate-related issues.\n  - DNS configuration weaknesses.\n\n## Prohibited conduct\n\nThe following actions are strictly forbidden:\n\n- DoS or DDoS attacks.\n- Threats, intimidation, or any harmful actions directed at company employees.\n\n## Report submission requirements\n\nA valid report must include a clear description of the vulnerability together with concise reproduction steps or a working proof of concept. Screenshots and videos may be included as supporting material, but they cannot replace the written explanation.\n\nIf the report lacks enough detail, the review process may be delayed significantly. It is also strongly encouraged to explain the method used to discover the issue.\n\n## Review process\n\nAll submissions are reviewed by the company’s security analysts. Severity assessment and any potential reward are determined based on the worst-case realistic exploitation scenario.\n\nReports are reviewed within 15 days at most, although a response may arrive sooner. Researchers who want to stay anonymous are advised to use an alias when submitting reports.\n\n## Eligible submissions\n\nOnly reports submitted through the bug bounty platform interface may qualify for a bounty. The official submission time is the timestamp recorded by the platform.\n\n## Duplicate policy\n\nDifferent exploitation paths for the same underlying issue, or closely related issues, may be treated as duplicates if the security team determines that one report already contains enough information to resolve all of them.\n\nA report classified as known or duplicate is marked as Duplicate and is not eligible for a monetary reward. A duplicate may refer either to an earlier report from any bug bounty platform or to an internal issue already tracked by the security team. In most cases, the reporter of a duplicate will receive access to the original report or some related internal information. However, this may be withheld when the duplicate contains less useful information or a less significant exploitation path than the original.\n\nA report is considered a duplicate of another bug bounty submission when an earlier original report already exists in `New` or `Triaged` status, or when it updates a report in `N/A` or `Need more info` while that original report has remained in that status for less than one week, or already contains sufficient information provided by the original reporter.\n\nA report is considered a duplicate of an internal task when the security team is already tracking the same issue internally at the time the duplicate is submitted.\n\nRecently disclosed public 0-day or 1-day vulnerabilities may also be treated as duplicates for a limited period after public disclosure if the team is already aware of them from public sources and is actively working on mitigation or remediation.\n\n## Invalid reports\n\nA report that remains in `N/A` or `Need more info` status for more than one week without enough new information being provided may be treated as invalid and will not participate in the bug bounty process.\n\n## Reward decisions\n\nA reward is paid only to the first researcher who reports a specific vulnerability.\n\nThe final bounty decision is made within 30 days after triage at the latest, although the decision may be issued earlier. Once confirmed, the report will contain a message stating that the vulnerability has been validated and that a reward has been granted.\n\nPayments are made through [HackerOne](https://docs.hackerone.com/en/articles/8395706-payments).\n\n| Vulnerability                                                                                                                                   | Price | Severity |\n| ----------------------------------------------------------------------------------------------------------------------------------------------- | ----- | -------- |\n| Remote code execution (RCE)                                                                                                                     | 3000 | Critical |\n| Injections (SQLi or equivalent)                                                                                                                 | 1500 | Critical |\n| Local files access and manipulation (LFR, RFI, XXE)                                                                                             | 1200 | Critical |\n| Admin / support interface authentication bypass                                                                                                 | 1500 | Critical |\n| SSRF, non-blind (with ability to read reply text), except dedicated proxies                                                                     | 1300 | High     |\n| SSRF, blind, except dedicated proxies                                                                                                           | 750   | High     |\n| Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of application critical or highly confidential data            | 1000  | High     |\n| Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of sensitive client/infrastructure data (bulk, no user action) | 750   | High     |\n| Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of sensitive client/infrastructure data (non-covered)          | 400   | High     |\n| Account takeover                                                                                                                                | 1500   | High     |\n| Admin / support interface blind XSS                                                                                                             | 1500 | High     |\n| Cross-Site Scripting (XSS)*                                                                                                                     | 150   | Medium   |\n| Subdomain takeover                                                                                                                            | 50    | Low      |\n\n\\* self-XSS, XSS specific to non-common browsers (e.g. IE), blocked by CSP and another vectors without proven script execution are usually accepted without bounty. Unused subdomain takeover is considered under same severity / conditions as parent domain XSS.\n","has_open_scope":true,"pays_within_one_month":true,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":"At 1win, cybersecurity is one of our main concerns. If you think you’ve identified a vulnerability within our designated applications or infrastructure, we welcome your report and are committed to collaborating with you to address the issue quickly. We also ensure you receive appropriate recognition and compensation for your findings.\n\nSubscribe to our [Telegram](https://t.me/bugbounty_1win) channel.\n\n==**Here is an incomplete list of countries where the 1win.com website is available: Brazil, Albania, Vietnam, Gibraltar, Zimbabwe, Israel, Indonesia, Malaysia, Kuwait, Jamaica, Japan, Panama, Thailand, Taiwan, Turkey, Philippines, South Korea, India, Bangladesh, Pakistan, Nepal, Kyrgyzstan, Azerbaijan, Uzbekistan, Tajikistan, Armenia, Chile, Argentina, Colombia, Ecuador, Venezuela, Bolivia, Cameroon, Egypt, Zambia, Costa Rica, Algeria, Angola, Andorra, Gabon, Guatemala, Guinea-Bissau, Honduras, Mozambique, Monaco, Mongolia, Namibia**==","platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2026-04-01T10:32:22.631Z"},{"id":3771977,"new_policy":"The scope of this 1win’s Vulnerability Disclosure Program Policy is limited to searching for technical vulnerabilities in the company's services.\n\n**We will not pay a reward (and we will be really upset) if we detect:**\n* Social engineering directed at the company's employees\n* Attempt to access arbitrary user's account or data or another vulnerability post- exploitation not required to demonstrate the bug presence\n* Distributed network/request flooding and other resource exhaustion attacks. Automated scanning tools must be limited to 5 request per second (300 requests per minute) to one target host summing up all tools and threads running in parallel and must not exceed 5 parallel requests at the same time (5 threads).\n\nPlease use your own accounts, phone numbers, etc to conduct your research. Do not try to gain access to others' accounts or any confidential information. When testing the feedback functionality, sending a message to technical support, etc., be sure to specify the subject Test and use [hacker email alias](https://docs.hackerone.com/hackers/hacker-email-alias.html).\n\n**We do not initiate security investigations regarding:**\n* Messages from security scanners and other automated systems without clear PoC and impact;\n* Vulnerability reports based on software/protocol versions not indicating the actual usage/exploitation;\n* Reports about the absence of a protection mechanism or non-compliance with recommendations (for example, the absence of a CSRF token) without indicating real negative consequences;\n* Self-XSS;\n* Framing;\n* Social engineering;\n* Clickjacking;\n* SPF/DKIM/DMARC issues;\n* Man-in-the-Middle attacks;\n* Vulnerabilities in partner services and products that do not directly affect the security of the company's services;\n* Infrastructure vulnerabilities, including:\n  * Server configuration issues (e.g. open ports, TLS versions, etc.);\n  * Issues related to SSL certificates;\n  * DNS configuration issues\n\n**Strictly prohibited actions:**\n* DoS / DDoS attacks;\n* Threats/harm to company employees.\n\n**How do I submit a bug report?**\nA bug report must give a detailed description of the discovered vulnerability and brief steps to reproduce it, or a working proof-of-concept. Video and screenshots can illustrate bug report, but can not replace it.\n\nIf you do not describe the vulnerability in sufficient detail, the discovery process is significantly prolonged and that doesn't help anybody. It's also very desirable if researcher can explain how exactly he or she found a given vulnerability.\n\n**How are bug reports examined?**\nReports about vulnerabilities are examined by our security analysts. Our analysis is always based on worst case exploitation of the vulnerability, as is the reward we pay.\n\nReports are reviewed within 15 days (this is a maximum period - we'll probably respond sooner). If you prefer to remain anonymous, we recommend using an alias when submitting bug reports.\n\n**Participating reports**\nOnly reports reported via bug bounty platform interface may be considered for a bounty. A date/time of report on bug bounty platform is considered as a date/time of the report.\n\n**Duplicate reports**\nDifferent exploitation vectors for the same bug or similar bugs may be considered duplicating if the security team believes information provided for a single vector/bug is enough to fix all vectors or bugs reported.\n\nReport for known or duplicating vulnerability is considered as Duplicate. Duplicate reports are not eligible for monetary reward. Report can be either a duplicate of another report from any bug bounty platform or a duplicate of the problem internally tracked by 1win security team. Usually, access to the original report or some information from the internal task tracker is provided to the reporter of Duplicate. In some cases information may not be provided, if a Duplicate contains less information or less critical exploitation vector than the original report.\nThe report is considered as a duplicated to another report from any bug bounty platform, if there is original report is in \"New\" or \"Triaged\" state with an earlier report date/time or lower report number of if it updates the report in \"N/A\" or \"Need more info\" state and original report is in \"N/A\" or \"Need more info\" state for less than 1 week or sufficient information is provided in original report by researcher since the report is transferred to \"N/A\" or \"Need more info\" state.\n\nThe report is considered as a duplicate to an internal task if there is a task in the internal task tracker which is tracked by the 1win security team at the time of the duplicate report.\n\nAlso, public 0-day/1-day vulnerabilities may be considered as a duplicate within a few days after vulnerability details publication, if the vulnerability is known to our team from public sources and we are working to mitigate or patch it.\n\n**Invalid reports**\nReport in \"N/A\" or \"Need more info\" state which is stale in this state for more than a week without sufficient new information provided is considered as invalid and does not participate in bug bounty.\n\n**Reward payment**\nWe will pay you a reward if you are the first person to report a given vulnerability.\n\nThe bounty decision will be made within 30 days after triage (this is a maximum period - we'll probably award sooner). A message will appear in your bug report, indicating that the vulnerability you reported has been confirmed and a reward has been granted.\n\nPayments are made through [HackerOne](https://docs.hackerone.com/en/articles/8395706-payments).\n\n| Vulnerability                                                                                                                                   | Price | Severity |\n| ----------------------------------------------------------------------------------------------------------------------------------------------- | ----- | -------- |\n| Remote code execution (RCE)                                                                                                                     | 3000 | Critical |\n| Injections (SQLi or equivalent)                                                                                                                 | 1500 | Critical |\n| Local files access and manipulation (LFR, RFI, XXE)                                                                                             | 1200 | Critical |\n| Admin / support interface authentication bypass                                                                                                 | 1500 | Critical |\n| SSRF, non-blind (with ability to read reply text), except dedicated proxies                                                                     | 1300 | High     |\n| SSRF, blind, except dedicated proxies                                                                                                           | 750   | High     |\n| Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of application critical or highly confidential data            | 1000  | High     |\n| Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of sensitive client/infrastructure data (bulk, no user action) | 750   | High     |\n| Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of sensitive client/infrastructure data (non-covered)          | 400   | High     |\n| Account takeover                                                                                                                                | 1500   | High     |\n| Admin / support interface blind XSS                                                                                                             | 1500 | High     |\n| Cross-Site Scripting (XSS)*                                                                                                                     | 150   | Medium   |\n| Subdomain takeover                                                                                                                            | 50    | Low      |\n\n\\* self-XSS, XSS specific to non-common browsers (e.g. IE), blocked by CSP and another vectors without proven script execution are usually accepted without bounty. Unused subdomain takeover is considered under same severity / conditions as parent domain XSS.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2026-04-01T10:19:05.928Z"}]