1win

Program scope

This program covers technical security issues in 1win-owned services listed in the Scope section, including the 1win Partners affiliate program.

Cases not eligible for a reward

No bounty will be paid, and such activity may lead to a negative response, if any of the following is identified:

• Social engineering attempts targeting company personnel.
• 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.
• 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.

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

Issues that are out of scope

Security investigations will not be opened for the following:

• Alerts or messages generated by automated scanners or other tools when there is no clear proof of concept and no demonstrated impact.
• Reports based only on software or protocol versions, without evidence of actual exploitability or practical security impact.
• 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.
• Self-XSS.
• Framing.
• Social engineering.
• Clickjacking.
• SPF, DKIM, or DMARC issues.
• Man-in-the-middle scenarios.
• Vulnerabilities in products, services or infrastructure of third-party vendors (game providers, payment providers, SaaS and other external services) that do not directly compromise 1win services or users. Games on 1win.com/casino and payment flows on 1win.com stay in scope as described in their assets. The 1win Partners affiliate program is a 1win-owned service and is not covered by this exclusion.
• Websites, apps and channels run by independent affiliates who promote 1win.
• Infrastructure-level findings, including:
  • Server-side configuration issues such as open ports or supported TLS versions.
  • SSL/TLS certificate-related issues.
  • DNS configuration weaknesses.

Prohibited conduct

The following actions are strictly forbidden:

• DoS or DDoS attacks.
• Threats, intimidation, or any harmful actions directed at company employees.

Report submission requirements

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

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

Review process

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

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

Eligible submissions

Only reports submitted through the bug bounty platform interface may qualify for a bounty. The official submission time is the timestamp recorded by the platform.

Duplicate policy

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

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

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

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

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

Invalid reports

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

Reward decisions

A reward is paid only to the first researcher who reports a specific vulnerability.

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

Payments are made through HackerOne.

¹ Payment & financial-logic — what each row covers

• Fund movement / crediting: anti-fraud/limit/hold bypass on payout, provider deception, unauthorized balance credit.
• Verification bypass / double-credit: paid-without-payment, UTR reuse, gateway bypass, duplicate payout via race/replay.
• Business-logic gain: bonus/voucher abuse, deposit/withdrawal limit bypass, currency-conversion abuse.

Reward rules (¹). A financial reward requires a server-side PoC proving a completed, settled money movement (credited balance ↑, real payout, or loss to 1win) with before/after evidence and the actual provider transaction where relevant. Burden of proof is on the reporter; use only your own funds/accounts. Tampering with a client field (amount, bonusId, currency, session, returnUrl, signature/timestamp) counts only if the backend settles on the tampered value after reconciliation — an echoed value, an HTTP 200, or a created-but-uncredited deposit/withdrawal is not impact.

Accepted without bounty (Informative), regardless of self-scored CVSS:

• tampering where the settled amount is unchanged
• "signature/timestamp doesn't cover field X" without a settled change
• IDOR/BOLA returning generic/public data or only enumeration
• missing CAPTCHA / rate-limit / IP-allowlist without proven loss
• already-public payment config or agent data
• replay of idempotent / non-financial actions

The amount within a range is set by the team on scale, reliability, coverage and privileges; severity is assessed on realized impact, not theoretical maximum.

² XSS. self-XSS, XSS in non-common browsers, CSP-blocked, or without proven script execution — usually no bounty. Unused subdomain takeover — same conditions as parent-domain XSS.