Security policy

Reporting a vulnerability.

CrashPilotX collects kernel logs, crash evidence, and resource telemetry from Linux machines and stores it in a multi-tenant database. Its agent runs as root. Security reports are welcome and taken seriously. For the design this policy covers, see the security model.

How to report

Email saqibkhan@crashpilotx.com with SECURITY in the subject line. Please do not open a public issue or disclose publicly before a fix is available and we have agreed on timing.

For issues in the agent you can instead use private vulnerability reporting on the agent repository, which keeps the report private until an advisory is published. If you need to send details encrypted, send a first message saying so without the details and a key will be arranged.

What to include

-What the issue is and which component it affects: dashboard, database schema, agent, installer, or webhooks.
-Steps to reproduce, ideally against your own account or your own Supabase project.
-What an attacker gains: whose data, read or write, and what they need to start with.
-For agent issues, the platform and the output of sudo crashpilot doctor.
-Whether you have shared this with anyone else, and any disclosure deadline you intend to hold to.

A working proof of concept helps, but a clear description of the flaw is enough. Do not withhold a report because you have not built an exploit.

What to expect

CrashPilotX is maintained by one person. These are realistic targets rather than aspirational ones.

Acknowledgement that the report arrived	5 business days
Initial assessment and severity call	10 business days
Fix for a critical issue on the hosted service	As quickly as possible, typically days
Fix for other issues	Tracked and released with the next change
Public advisory and credit	After a fix ships and self-hosters have had time to apply it

If you have not heard back within 10 business days, send a follow-up. Mail does get lost. Credit is given in the advisory unless you ask to stay anonymous. There is no paid bounty: this is an unfunded project, stated plainly so nobody spends time expecting otherwise.

Scope

In scope

-The hosted dashboard at crashpilotx.com.
-The Supabase data layer: SECURITY DEFINER RPCs, row level security policies, column grants, and triggers.
-The agent, its systemd units, its local REST API, the Docker image, and the Kubernetes DaemonSet.
-The installer served at crashpilotx.com/install.sh and the agent bundle it downloads and verifies.
-Outbound webhook delivery, including the guard that rejects private and link-local URLs.

Where to look first. The functions agent_heartbeat, agent_push_report, and agent_system_status run as SECURITY DEFINER with execute granted to the anonymous role. They authenticate only by matching a system id and agent token pair. Anything reachable through them is reachable by anyone holding the public anon key plus a token for any single system, including their own. Cross-account reads or writes through those functions, or through row level security on the dashboard tables, are the most serious class of bug in this project.

Out of scope

-Supabase, GitHub Pages, and other third-party infrastructure. Report those to the vendor.
-Self-hosted deployments that have not applied the published schema, or that have modified it.
-Attacks that require root on the monitored machine. The agent already runs as root there by design.
-Missing hardening headers, cookie flags, or raw scanner output with no demonstrated impact.
-Denial of service, volumetric testing, and rate-limit findings.
-Social engineering, phishing, and physical attacks.

Testing guidelines and safe harbor

Test against your own account and your own machines. Create an account, stand up your own Supabase project, or use the public demo, which needs no signup.

Do not attempt to read or modify another account's systems, crash reports, or telemetry. Because report ids are globally unique and appear in dashboard URLs, it is possible to construct a test that touches another tenant's data. Do not. Use two accounts you control if you need to demonstrate a cross-tenant issue. If you inadvertently access someone else's data, stop immediately, do not save or share it, and say so in your report.

Safe harbor: if you follow this policy in good faith, no legal action will be pursued over your research, and reports will not be treated as unauthorized access. If a third party brings action against you for work that followed this policy, that will be made clear to them.

How fixes reach you

CrashPilotX runs in two ways and they receive fixes differently. This matters.

Hosted. If you use the dashboard on crashpilotx.com, database and dashboard fixes are applied centrally. No action is needed.

Self-hosted. If you run your own Supabase project, schema fixes take effect only when you apply them. A patched function or policy stays vulnerable in your project until you run the SQL. Every advisory names the migration involved. Apply that file, or re-run the published schema, which is idempotent and safe to re-run on an existing database.

Agent. Update through the verified daily update timer if you enabled it during install, or re-run the installer. Confirm with sudo crashpilot doctor.

Supported versions and current limitations

Only the most recent release of the agent and the dashboard receives security fixes. There are no backports. This is a pre-1.0 project.

Stated openly so you can judge the risk yourself:

-No third-party security audit or penetration test has been performed.
-No formal incident response process or status page exists.
-No SOC 2, ISO 27001, or comparable certification.
-One maintainer, so response times depend on one person availability.

For what gets uploaded, how long it's kept, AI and model handling, and secret redaction, see Data Handling.