Responsible disclosure & bug bounty policy

Scope

What we pay

Demonstrated impact on our systems or our customers is what earns a reward. Amounts are in USD.

Rules of engagement

1. First valid report wins. If it is a duplicate or an issue we already know about, it is not paid. However many endpoints share it, a root cause gets a single payment.
2. Prove it, then stop. Access only your own accounts and data. A test that would expose someone else's data must end at the first proof, followed by a report — do not pivot, download or persist.
3. Do not degrade the service. Don't load test, don't run automated fuzzing at volume, and don't test proxy gateways, modem hosts or carrier networks. Those are out of scope entirely.
4. Give us time. Going public is not allowed until the issue is fixed and 30 days have passed. We will notify you when a fix is live.
5. Severity is ours to set. The Bugcrowd Vulnerability Rating Taxonomy is our reference when we rate impact on our own systems. The amount paid, within the ranges above, is at our discretion and goes out by PayPal or USDT.

What we do not pay for

These are accepted at no more than Low or Informational. We'll read them and fix what is worth it, but no bounty is issued, and calling the report Critical or High does not change the outcome.

• Session validity that persists past a password change, password reset or logout until the token expiry
• Security header gaps or “weak” settings (CSP, HSTS, X-Frame-Options, Referrer-Policy) without a working exploit
• Pages with no sensitive action that can be clickjacked
• Attributes of any cookies besides session cookies
• Enumerating usernames or emails, whether by error messages, timing or otherwise
• Rate-limit, login or forgot-password observations where no account takeover is demonstrated
• Opinions on password rules: length, complexity, common-password lists, no forced rotation
• Missing two-factor authentication, or 2FA that users may skip
• XSS that only the attacker can set off inside their own session, including Self-XSS
• CSRF in the login, logout or language forms, or other non-sensitive ones
• Open redirects where no token or credential is leaked
• Path, stack trace, server banner or software version disclosure where no sensitive data is exposed
• SPF, DKIM or DMARC configuration reports
• Automated scanner reports lacking a proof of concept
• Denial of service or resource exhaustion, brute forcing, or any test that puts load on systems
• Any physical attack, or social engineering or phishing of our staff or customers
• Issues in the third-party services we depend on: payment processors, Telegram, Cloudflare and email providers
• Older library versions where no working exploit exists against our deployment
• Attack paths that need a rooted phone, a man-in-the-middle position or a compromised device
• Known-issue duplicates, theoretical risks and best-practice recommendations

Policy last updated 2026-10-17.