Surfshark looks forward to working with the security community to find vulnerabilities in order to keep our businesses and customers safe.
We will pay you a reward if you are the first person to report a given vulnerability.
The 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.
Any activities conducted in a manner consistent with this policy will be considered authorized conduct, and we will not initiate legal action against you. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will make it known that your actions were conducted in compliance with this policy. Surfshark reserves all legal rights in the event of noncompliance with this policy.
What’s In Scope
Current versions of the official Surfshark Security Suite, consumer applications on all platforms:
- Browser extensions
- Surfshark VPN servers
- Surfshark API
- Surfshark websites
- Incogni websites
- Automated testing is not permitted.
- Test only with provided testing accounts when investigating bugs, and do not interact with other accounts without the consent of their owners.
- You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.
- We award bounties following our triage process and will keep you posted as we work to verify submissions. *We reserve the sole right to determine the size of the reward if any. We determine this on a case-by-case basis, depending on overall severity (including the business impact, creativity of the issue, etc.).
- You shall respect our final decision.
- You shall not contact the Surfshark support team about the status of a submitted report.
Requests for vulnerability disclosure must be submitted via mail: [email protected]. We usually disclosure reports within 4 weeks after disclosure request or fixing time, but we can request up to 3 months of additional time before vulnerability details are published. This time is required to distribute the fixed version and check it for regressions.
No vulnerability disclosure, including partial is allowed before vulnerability is disclosed.
If any sensitive information including (but not limited to) infrastructure and implementation details, internal documentation procedures and interfaces, source code, user and employees data accidentally obtained during vulnerability research or demonstration must not be disclosed. Intentional access to this information is strongly prohibited.
Surfshark does not disclosure and does not grant you any rights to disclosure vulnerabilities in 3rd party products or services, unless these rights are explicitly given to you by the affected 3rd party.
Until the vulnerability is patched, you are not allowed to publicly discuss or publish the vulnerability without our express permission to do so.
Reports are expected to be thorough and contain enough information that Surfshark’s security team can easily duplicate any findings. If specially crafted files are required, they should be submitted as attachments. Screenshots are encouraged while videos are discouraged, unless necessary. Submissions should not consist solely of a video.
Reports are welcome for issues that cannot be proven but still suggest a serious impact. We trust reporters to make that determination and will assist in clarifying impact and adjusting the severity as needed. It is better to report a vulnerability early while we help determine the impact rather than waiting days or weeks to create proof.
Surfshark reserves the right to modify the terms and conditions of this program, and your participation in the Program constitutes acceptance of all terms. Please check this site regularly as we routinely update our program terms and eligibility, which are effective upon posting.
- Vulnerabilities requiring physical access to the victim’s unlocked device, root/system privileges on, or MITM of a user’s device.
- User enumeration attacks – the ability to determine if an email address or username is in use.
- Attacks targeting outdated browsers or browsers other than Firefox, Chrome, Edge, or Safari.
- Insecure cookie settings / flags on non-login cookies.
- Weak SSL/TLS algorithms or protocols.
- Lack of certificate pinning (improper certificate validation still eligible).
- CSRF with no security impact (unauthenticated/logout/login CSRF).
- Best practices violations (password complexity, expiration, re-use, etc.).
- Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking issues.
- Previously known vulnerable libraries without a working Proof of Concept.
- Reflected file download.
- Content spoofing and text injection issues without being able to modify HTML/CSS.
- Homograph links.
- Mobile app crashes.
- Bypassing rate-limits or the non-existence of rate-limits that have no platform impact.
- Exposure of internal domains on public domains.
- Vulnerabilities only affecting users of outdated or unpatched browsers and platforms.
- Any other submissions determined to be low risk, based on unlikely or theoretical attack vectors, requiring significant user interaction or resulting in minimal impact.
- WordPress bugs (please report those to WordPress directly).
- OpenVPN bugs (please report those to OpenVPN directly).
- Out of date software – we do not always run the most recent software versions (patched).
- Anything related to credential stuffing and account takeover.
- Spam or Social Engineering techniques.
- Missing best practices, information disclosures, use of known-vulnerable libraries or descriptive / verbose / unique error pages (without substantive information indicating exploitability).
- HTTP TRACE or OPTIONS methods enabled.
- Reports related to the following security-related headers: o Strict Transport Security (HSTS) o XSS mitigation headers (X-Content-Type and X-XSS-Protection) o X-Content-Type-Options o Content Security Policy (CSP) settings (excluding nosniff in an exploitable scenario)
- Self-XSS and issues exploitable only through Self-XSS.
Non-sensitive (ie. non-session) cookies missing the Secure or HttpOnly flags.
- Bugs that do not represent any security risk.
- Application or server error messages, stack traces.
- Hardcoded API keys in applications (unless it constitutes a significant risk)
- “Scanner output” or scanner-generated reports.
- Publicly released bugs in internet software within 3 days of their disclosure.
- Denial of service attack.
|Windows: Microsoft Store||Surfshark|
|Other||Surfshark Chrome Extension|
|Other||Surfshark Firefox Extension|
|Other||Surfshark Edge Extension|
|Other||Surfshark VPN Application for Amazon Fire TV|
|Other||Desktop and Mobile apps|
|Android: Play Store||com.surfshark.vpnclient.android|
|Executable||Surfshark – Windows Executable|
|Executable||Surfshark – macOS Executable|
|iOS: App Store||1391782046|