Security policy

Reporting a security issue

Percher hosts other people's code, data and secrets, so a vulnerability in the platform is the most serious kind of bug we can have. If you have found one, we want to hear about it. This page says how, what counts, and what you can expect back.

We do not pay for reports

Percher has no bug bounty programme and offers no rewards of any kind: no payment, no one-off "thank you" amounts, no gift cards, no swag. This is not going to change with the severity of a finding or with negotiation.

Emails that ask whether we pay before sharing any details will not get a reply. If you have a finding, send it. If you would rather not share it without payment, we understand, and no reply is needed.

What we can do is credit you. If a report leads to a fix worth announcing, we name you in the changelog by whatever name you give us, or leave you out if you prefer.

How to report

Email security@percher.app with the subject line Percher security: <summary>. The same address is published in our security.txt. There is no web form and no ticket tracker; email is the only channel.

Please include:

What the issue is and what it allows. One or two paragraphs is usually enough.
Reproduction steps. The exact requests or code that demonstrate the problem against the live service (percher.run, percher.app, mcp.percher.app). Say which host, and roughly when you ran them.
Whether you have shared the finding with anyone else.

If the issue is critical and you need an encrypted channel, ask for a PGP key in your first email and we will exchange one before further details.

Content hosted on Percher, such as phishing, malware or spam, is not a platform vulnerability. Report it to abuse@percher.app instead; the Acceptable Use Policy describes how those reports are handled.

What to expect

Percher is a small operation, so treat these as intentions rather than guarantees.

A reply within a week to a report that contains a finding. Anything on the in-scope list below is looked at as soon as we see it.
One of three answers: a fix in progress, a question, or why we do not consider it a security issue.
A request to hold public disclosure until a fix has shipped. Publishing an unpatched issue gives attackers the same information defenders have, without the time to fix it. If a fix looks like it will drag, say so and we will agree a date rather than leave it open-ended.

In scope

These are treated as security bugs:

Cross-tenant access. One user reading or modifying another user's apps, environment variables, deploy logs, backups or PocketBase data.
Container escape. User code breaking out of its app container into the worker, the API or the host.
Authentication bypass. Reaching the API or dashboard without a valid session, or as a different user.
Backup integrity. A restore that produces a different state than the captured instant, or decrypting backups without the key.
Supply-chain compromise. A malicious dependency, image or upstream action that we ship to production.
Secret leakage. Credentials, encryption keys or session tokens exposed through logs, error messages, the dashboard or the API.

Out of scope

Not security bugs unless they enable one of the above:

Denial of service by traffic volume against a single app on the free plan. That is an abuse-control and billing concern.
Self-XSS in fields the attacker controls that only affects their own session.
Outdated dependencies with no known exploit and no upstream advisory.
Output from automated scanners with no demonstrated impact.
Missing or "weak" email, DNS or HTTP header configuration (SPF, DMARC, DKIM, CSP, HSTS, clickjacking, cookie flags and the like) without a working exploit.
Theoretical timing attacks against constant-time code paths.

Testing safely

Test against your own account and your own apps. Do not access, modify or delete data that belongs to another user, and do not run volume-based or destructive tests against the shared platform. If you reach something you should not be able to reach, stop there and tell us what you saw rather than going further.

Past advisories

None published yet. When a fix matters to customers we say so in the changelog and email the affected accounts directly.