Reporting a vulnerability.

What is in scope

These are the hosts we operate and can actually fix.

What is not

• The upstream services our projects read from. We do not own them, cannot fix them, and will not forward reports about them on your behalf — report those to their owners directly.
• Findings that require an already-compromised device, a malicious browser extension, or physical access.
• Missing hardening headers, cookie flags on cookies we do not set, or scanner output with no demonstrated impact.
• Rate limiting on the contact form. See the known limitation below — you do not need to report it.
• Denial of service, traffic flooding, and load testing. These are prohibited rather than merely out of scope.

What to include

• What the issue is, in one or two sentences.
• The exact steps to reproduce it, including any request or payload.
• The host and, where relevant, the version or commit.
• What an attacker could actually do with it.
• Whether you want to be credited, and the name to use.

What happens next

• We acknowledge within 72 hours. That is the same commitment the SECURITY.md in our repositories makes.
• You get told what we found and what we intend to do about it, including if the answer is that we will not fix it.
• Fixes ship as soon as they are ready. There is no fixed disclosure window because the projects are small enough that the honest answer is "quickly, or we will tell you why not".
• If you want credit, you get it. If you would rather stay anonymous, that is fine too.

Safe harbour

Research carried out within these limits is authorised, and we will not pursue or support any legal action against you for it. Stay inside them.

• Test only against the hosts listed above, and only with accounts and data that are yours.
• Stop as soon as you have shown the issue exists. Do not read, copy, modify or retain anyone else’s data.
• No denial of service, no automated scanning that degrades the service, no spam, and no social engineering of anyone.
• Give us a reasonable chance to fix it before telling anyone else.

Rewards

There is no bug bounty and no payment. This is a micro enterprise, and offering a reward we could not reliably honour would waste your time. What we can offer is a fast, human reply and public credit.

Known limitations

Published so nobody spends an afternoon rediscovering something we already know and decided about.

The contact form rate limiter is not a security boundary

It runs in memory inside a single server instance, so each isolate keeps its own counter and every restart resets it. It is enough to blunt a naive script and nothing more. Cloudflare Turnstile is the real gate on that form, and this is documented in the source rather than assumed to be understood.

Several projects deliberately keep working when upstream blocks them

Some of our APIs present a consistent browser identity to the sources they read, because those sources reject datacentre traffic outright. That is a design decision about reading public data, not an attempt to defeat authentication, and there is no credential or access control being bypassed anywhere in it.

security.txt

Machine-readable contact details are published at /.well-known/security.txt per RFC 9116. It expires on 4 September 2027; the same date is shown here so that a lapse is visible on the page rather than only inside a file nobody opens.