TinyBoost security

Vulnerability Disclosure Policy

Last updated: 8 October 2026

TinyBoost welcomes security research that helps protect our customers, applications, and services. This policy explains how to report a suspected vulnerability, the boundaries for authorized testing, and what researchers can expect from us.

1. Reporting a vulnerability

Send reports to tinyboost@fpsheaven.com and include SECURITY in the subject line. For example: SECURITY — Brief description of the issue.

Please include:

  • The affected application version, URL, or endpoint.
  • A description of the issue, its potential impact, and any prerequisites.
  • Clear reproduction steps, preferably using a minimal proof of concept.
  • Relevant requests, responses, or screenshots, with sensitive information removed.
  • For desktop findings, the executable version, download source, and SHA-256 hash where available.

You do not need a complete exploit to report a concern. Clearly distinguish observed behavior from suspected impact, and identify any steps you have not tested.

Do not include passwords, active session tokens, or other customers' information in ordinary email. Contact us first if sensitive evidence requires a secure transfer method.

2. Scope

This policy authorizes limited, non-disruptive security research on:

  • Officially distributed TinyBoost Windows application: local inspection, reverse engineering, and testing on devices you own or have permission to use.
  • https://tinyboost.app: public website and application features, using accounts and data you control.
  • https://fpsheaven.com/updates/: TinyBoost download distribution and update integrity, without modifying hosted content or disrupting downloads.

Other subdomains, administrative interfaces, infrastructure, and unrelated FPSHeaven services are not included in this testing authorization. Contact us before actively testing an asset that is not listed.

We welcome reports about weaknesses in TinyBoost's integrations and configurations. This policy does not authorize testing systems belonging to Cloudflare, Stripe, Google, Discord, Shopify, or other providers. Vulnerabilities in those providers' own products should also be reported through their respective disclosure channels.

3. Research requirements

Use accounts, devices, and data you control. When testing account isolation, use separate accounts that you own.

Limit testing to the minimum necessary to establish the issue and its impact. Stop once you have sufficient evidence to report it.

The following activities are prohibited:

  • Accessing, modifying, deleting, or collecting another person's data.
  • Using credentials, tokens, or secrets that do not belong to you, including publicly exposed credentials.
  • Denial-of-service testing, resource exhaustion, or automated testing that causes excessive traffic or service degradation.
  • Credential stuffing, password spraying, phishing, or social engineering.
  • Installing malware, establishing persistence, moving laterally, or continuing exploitation beyond the initial proof of concept.
  • Altering production systems, manipulating real customer transactions, or making destructive changes.

Low-volume automated testing is permitted on listed assets when it complies with these requirements. Contact us before testing if you cannot reasonably predict its impact.

If you unexpectedly encounter sensitive information or gain access beyond your own account, stop immediately and notify us. Do not investigate further, share the information, or retain unnecessary copies.

4. How we assess reports

We assess reports based on demonstrated impact, reproducibility, affected users, required privileges, and realistic attack conditions.

A report should explain how the behavior could compromise confidentiality, integrity, availability, or an intended security boundary.

The following generally require additional evidence before they can be treated as security vulnerabilities:

  • Automated scanner findings without manual verification.
  • Dependency-version matches without evidence that the vulnerable behavior affects TinyBoost.
  • Missing security headers or recommended hardening measures without a demonstrated consequence.
  • Readable strings, implementation details, or protocol names in an executable.
  • Public information or downloads that are intentionally available.
  • Changes to a researcher's own client that do not demonstrate a failure of an intended security control.

These are assessment guidelines, not blanket exclusions. Reports demonstrating sensitive-data exposure, unauthorized access, or another concrete security impact remain welcome.

5. Our response

We aim to acknowledge reports within five business days. This is a response target, not a guaranteed resolution deadline.

We will review the evidence and may request clarification or additional reproduction details. For validated findings, we aim to:

  • Explain our assessment and prioritization.
  • Provide meaningful updates as the investigation progresses.
  • Develop and validate an appropriate remediation.
  • Coordinate verification and disclosure with the reporter.

Resolution time depends on severity, complexity, dependencies, and the risk of disrupting customers. If you have not received an acknowledgment within five business days, please follow up in the same email thread.

6. Coordinated disclosure

Please report vulnerabilities privately before publishing details that could enable exploitation.

We request up to 90 days from receipt of the initial report to investigate and address the issue. We may agree on earlier disclosure or request an extension with a clear explanation. Extensions should be mutually agreed.

If active exploitation or an immediate threat to users changes the urgency, contact us promptly so we can coordinate protective action and disclosure.

Public disclosures must not include customer data, active credentials, or other sensitive information. We welcome accurate technical write-ups and will coordinate acknowledgment where appropriate.

7. Good-faith research and safe harbour

For research conducted in good faith within this policy, TinyBoost will not initiate legal action against the researcher. We consider such research authorized on the assets listed in scope.

Solely for research permitted by this policy, we waive restrictions in our own applicable terms that would otherwise prohibit that research, including restrictions on reverse engineering the official TinyBoost client.

An accidental policy violation does not automatically remove this protection. If you unintentionally cross a boundary, stop, notify us promptly, and cooperate in limiting any harm.

This authorization applies only to systems and rights we control. It cannot authorize activity against third parties or prevent third parties from taking action.

If you are uncertain whether a proposed activity is permitted, contact us before proceeding.

8. Recognition and rewards

We reward valid security findings with payments we consider fair, taking into account demonstrated impact, report quality, and the project's available resources. Each report is assessed individually, and any payment amount is confirmed in writing.

As TinyBoost grows, we intend to introduce a formal reward system with published severity tiers and payment ranges. Until then, we do not offer fixed amounts or guaranteed minimum payments.

With your permission, we may also publicly acknowledge your contribution.

9. Policy updates

We may revise this policy as our products and services change. Updates apply to future research and will not retroactively withdraw authorization for activity that complied with the policy in effect when it occurred.

Security contact: tinyboost@fpsheaven.com
Email subject: include SECURITY.