Responsible disclosure & bug bounty policy

Scope

What we pay

To earn a reward, you need to show real impact on our systems or our customers. Amounts are in USD.

What we do not pay for

The most these can be accepted as is Low or Informational. We'll read them and fix whatever's worth fixing, but there's no bounty, even if the report is labelled Critical or High.

• Staying logged in after a password reset, password change or logout, until the session token runs out
• No working exploit, just missing or “weak” security headers (CSP, HSTS, X-Frame-Options, Referrer-Policy)
• Clickjacking on a page where there's no sensitive action
• The attributes on any cookie that isn't a session cookie
• Working out emails or usernames, including from timing or error messages
• Notes on forgot-password, login or rate limits that don't show an actual account takeover
• Your take on our password rules: length, complexity, common-password lists, no forced rotation
• Not offering two-factor authentication, or making 2FA optional
• Self-XSS, or XSS you can only set off yourself in your own session
• CSRF on forms that aren't sensitive: login, logout, language and the like
• Open redirects that don't give away a token or credential
• Showing a software version, server banner, stack trace or path, if no sensitive data comes with it
• SPF, DKIM or DMARC configuration reports
• Whatever an automated scanner spits out, if there's no proof of concept
• Any test that generates load, including denial of service, resource exhaustion and brute force
• Physical attacks, and phishing or social engineering aimed at our staff or customers
• Problems with third parties we use: email providers, Cloudflare, Telegram, payment processors
• Library versions that are out of date but have no working exploit against our deployment
• Attacks where you'd already need a man-in-the-middle position, a compromised device or a rooted phone
• Best-practice tips, risks that are only theoretical, and repeats of issues we already know about

Policy last updated 2026-11-08.

Rules of engagement

1. First valid report wins. If it's a duplicate or something we already know about, there's no payment. We pay once per root cause, however many endpoints it hits.
2. Prove it, then stop. Access only your own accounts and data. If your test would show someone else's data, stop at the first proof and tell us. Don't 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 against proxy gateways, modem hosts or carrier networks. Those are out of scope entirely.
4. Give us time. Don't publish until we've fixed the issue and 30 days have gone by. We'll let you know once the fix is live.
5. Severity is ours to set. We judge impact on our own systems and use the Bugcrowd Vulnerability Rating Taxonomy as the reference. We decide the amount, at our discretion, within the ranges above, and we pay it by PayPal or USDT.