Reporting a vulnerability

Last updated: October 9, 2026

How to report a security problem in Pathbound, and what to expect from us. For how data is protected, see our Trust page.

Pathbound does not run a bug bounty program of any kind, and we do not pay for vulnerability reports. This page is not an invitation to test our systems.

1. Reporting a vulnerability

Write to [email protected]. Tell us what you found, where, how to reproduce it, and what an attacker would gain from it; a short proof is worth more than a long description. If the report contains personal data or a secret, say so in the first line and send only what we need to see the problem.

  • We answer within 3 business days to say we have your report, unless it is one of the kinds in section 3.
  • We tell you what we concluded, and when the fix is deployed.
  • We do not pay for reports and do not discuss payment. We will credit you by name if you would like that.
  • Please give us 90 days, or until the fix is deployed if that is sooner, before you publish.

2. What we do not permit

We have not opened our systems for testing. Nothing on this page, and nothing in our security.txt file, gives permission to probe, scan, or attack Pathbound.

  • Reporting something you noticed while using your own Pathbound account in the ordinary way needs no permission.
  • Anything beyond that needs our written agreement first. Write to us before you start, not after.

Even with our agreement, never:

  • read, change, or delete data that is not yours. If you come across someone else’s data, stop, keep no copy, and tell us
  • degrade the service: no denial of service, no load testing, no scanning at a rate others would notice
  • target people: no phishing or social engineering of our customers or of us
  • send unsolicited messages through the product

This page covers the services we run ourselves under pathbound.ai. It does not cover the third parties we use, such as Cloudflare, Paddle, or PostHog, or the tools our customers connect; a problem in one of those is theirs to hear about.

3. Reports we do not answer

We read everything sent to that address. We do not answer, or act on, a report of the following kinds unless it shows how the finding leads to someone’s data or account:

  • the output of an automated scanner, without a working demonstration
  • HTTP security headers, cookie flags, or TLS settings that could be stricter
  • SPF, DKIM, or DMARC settings
  • clickjacking on a page that performs no sensitive action
  • names and version numbers of software we run
  • rate limits on a page that signs nobody in
  • an attack that needs the victim’s unlocked device or an out-of-date browser, or that the victim carries out on themselves
  • a message that asks for payment before it gives the details

4. If you report in good faith

We will not pursue or support legal action against someone who reported a problem to us in good faith and kept to this page: who found it through ordinary use of their own account or with our written agreement, did none of the things section 2 rules out, and gave us the time in section 1 before publishing. If a third party brings a claim against you over such a report, we will say that you acted within this page. This is a promise about what we will do. It does not authorize testing. If you are unsure whether something is allowed, ask first.

5. What we do with a report

How we rate a confirmed vulnerability, the time we give ourselves to fix it, and how we handle an incident are on our Trust page, with what protects customer data today.