trackslash Security Policy

Version: 2026-07-18
Last updated: 18 July 2026

trackslash is under active development and has no supported stable release. Security reports affecting the current default branch or the Bad Bundle-operated development preview at trackslash.com are welcome.

Reporting a vulnerability

Email [email protected] with:

• a description of the issue and its potential impact;
• the affected route, component, commit, or deployment;
• clear reproduction steps or a proof of concept;
• any suggested mitigation; and
• how you would like to be credited, if at all.

Do not include secrets or personal information that are not needed to explain the report. Do not report suspected vulnerabilities through public issues, project comments, or public project content.

Coordinated disclosure

Please allow time for us to investigate and address a report before publishing it. We do not promise a fixed response or remediation time, but we will try to acknowledge actionable reports and keep reporters informed when practical.

When researching a suspected issue:

• use accounts, projects, and data you are authorised to access;
• avoid privacy violations, service disruption, social engineering, spam, denial of service, and destructive testing;
• stop if you encounter another person's information and report the exposure without retaining or sharing it; and
• do not demand payment or threaten disclosure.

This project does not currently operate a bug-bounty programme and does not promise payment or other rewards.

Self-hosted installations

Independent operators are responsible for securing, updating, monitoring, and backing up their own installations. A report about a specific independent deployment should normally be sent to that deployment's operator unless the underlying issue also affects track-slash itself.