Security

Responsible Disclosure

patchletter tells administrators when their software needs patching. A service that says that had better be able to take a report about itself. If you have found a security issue, tell us first and give us time to fix it — this page says exactly what you get in return, with dates attached.

What makes a report useful

• the affected URL
• request and response
• a rough timestamp, so we can match it against our logs
• the impact you were actually able to demonstrate

The timestamp is the one people leave out most often and the one that saves us the most work: without it we cannot hold your finding against our logs.

What you can expect

1. 01

   Acknowledgement

   3 working days

   You get a reply from a person, not an automated receipt. If it fails to arrive, the mail did not reach us — write to the second address.

2. 02

   Validation

   14 days

   We tell you whether we could reproduce the finding, how we rate it, and whether it was already known. A “not a finding” comes with reasons too.

3. 03

   Confidentiality both ways

   We pass on neither your report nor your name while the finding is open. We ask the same of you — see the embargo below.

4. 04

   Fixing

   Status update every 14 days

   While the finding is open you hear from us at least this often — including when there is nothing new. You should not have to chase us.

5. 05

   Credit

   On request we credit you by name in the changelog, with a link if you like. There is no money — see “No bug bounty”.

What we ask of you

• Give us 90 days before you publish anything. If the fix genuinely needs longer, we will say so and ask — we will not go quiet on you.
• Stay within your own data. Use an account you created yourself; do not read, change or delete anything that belongs to somebody else.
• Do not degrade the service for others — no load tests, no rate-limit probing, no denial of service.
• Stop at proof. Once you can demonstrate the impact, you have what you need; going further does not make the report better.

What interests us most

• Access to other people's subscriptions or email addresses — the email address is the only personal data we store at all.
• Bypassing the magic-link sign-in or the session handling.
• Tampering with version or release data — the core of the product: whoever can lie here keeps admins away from real patches.
• Anything that lets third parties send mail through our systems.
• Access to the admin area.

Out of scope

• Scanner output without a demonstrated impact.
• Missing headers without a concrete attack path.
• Load or rate-limit tests that degrade the service for others.
• Social engineering or phishing against operators or users.
• Real user accounts — create your own account for testing.

This list saves you effort on reports we would close anyway. It is not a shield: show one of these with a real, demonstrated impact and it is a valid finding.

No bug bounty

patchletter is a free, independent project. There is no bounty programme and no payout — we would rather say that plainly here than let you find out after the work is done. What we can offer: a fast, honest process, credit by name in the changelog if you want it, and the knowledge that the finding actually got fixed.

Safe harbour

We will not take legal action over good-faith research that stays within the rules on this page, and we will not report you to anyone for it. If you are unsure whether something is within the rules, ask us before you try it — the address above answers that too.

Machine-readable

The same addresses, the same scope and the same key are published under /.well-known/security.txt (RFC 9116), which points back at this page as its policy. Which machines process your data, and how to verify that yourself, is on where patchletter runs.