Terms & policies

Vulnerability disclosure policy

We take our systems' security seriously, and we value input from the security community. If you've discovered a vulnerability, we appreciate your help in disclosing it to us.

Last updated: November 2025

The disclosure of security vulnerabilities helps us to ensure the security and privacy of our users. In order maintain the security and privacy of both researchers and our users, we require that any potential submissions are made inline with the following outline.

Guidelines

You must NOT:

Break any applicable law or regulations.
Access unnecessary, excessive or significant amounts of data.
Modify data in Superthread’s systems or services.
Use high-intensity invasive or destructive scanning tools to find vulnerabilities.
Attempt or report any form of denial of service, e.g. overwhelming a service with a high volume of requests.
Disrupt Superthread’s services or systems.
Submit reports detailing non-exploitable vulnerabilities, or reports indicating that the services do not fully align with “best practice”, for example missing security headers.
Socially engineer, ‘phish’ or physically attack the Organization's staff or infrastructure.
Demand financial compensation in order to disclose any vulnerabilities.

You must:

Always comply with data protection rules and must not violate the privacy of any data Superthread holds. You must not, for example, share, redistribute or fail to properly secure data retrieved from the systems or services.
Securely delete all data retrieved during your research as soon as it is no longer required or within 1 month of the vulnerability being resolved, whichever occurs first (or as otherwise required by data protection law).

Within scope

The following services are within the scope of this disclosure program:

Out of scope

To keep the program focused on meaningful security risk, the following types of reports do NOT qualify for a bounty and should not be submitted:

Issues that require valid authenticated user access:
- Bugs that let a legitimate logged-in user do more than intended within their own account are out of scope, unless they can be exploited without valid credentials to gain additional, unauthorized access.
Account/usage-limit workarounds that are not security issues:
- Ways to reset or change usage counters.
- Unlock gated features, or otherwise "game" business logic that do not expose other users' data or provide unauthorized access.
Bugs that require additional privileged information or third-party credentials:
- Findings which are only reproducible with private keys, secret tokens not in scope, or credentials that were not issued by us.
Issues that do not affect confidentiality, integrity, or availability:
- Cosmetic UI bugs.
- Typos.
- Missing non-critical security headers.
- Revealing information that is already publicly available.
Social engineering:
- Exploits that rely on tricking users or Superthread employees such as phishing, physical attacks, or phone/SMS-based manipulation are not accepted.
Performance, reliability, or general support issues:
- Page rendering problems.
- Intermittent timeouts.
- Feature requests or usability problems.

If you are unsure whether a finding is eligible, include a short risk statement in your report explaining how the issue could be used to gain unauthenticated access, elevate privileges, exfiltrate sensitive data, or otherwise cause material harm.

Safe harbor

If you follow these guidelines when reporting an issue to us, we commit to:

Not pursue or support any legal action related to your research.
Work with you to understand and resolve the issue quickly (including an initial confirmation of your report within 72 hours of submission).
Offer monetary reward for the vulnerability in the case that it hasn’t already been reported and it is poses a significant, exploitable threat to our systems or services.

How to report a security vulnerability?

If you believe you have found a security vulnerability relating to a Superthread system, please submit a vulnerability report to [email protected].

In your report please include details of:

The website, IP or page where the vulnerability can be observed.
A brief description of the type of vulnerability, for example; “XSS vulnerability”.
Steps to reproduce. These should be a benign, non-destructive, proof of concept. This helps to ensure that the report can be triaged quickly and accurately. It also reduces the likelihood of duplicate reports, or malicious exploitation of some vulnerabilities, such as sub-domain takeovers.