Bug bounty programme
Found a security bug? Report it here.
If you have found a security problem in anything we run (this site, a client system we host, or software we wrote), we want to hear about it. This page tells you how to reach us, what we will do with the report, and what we ask of you in return.
- First reply within 48 hours
- Fix or a date within 90 days
- Recognition-based bug bounty: credit, not cash
- Open for bug bounty reports
The policy
What we do, and what we ask.
We read every report. You will get an acknowledgement within two business days and a decision within ten, and we will tell you when the fix ships.
A note on the word: this is a recognition-based bug bounty programme. We do not pay cash rewards today, and we would rather say so here than let you spend an evening on it and find out afterwards. What a valid bug bounty submission earns is a fast human reply, a named credit in the hall of fame below, written confirmation of the finding and its fix, and a reference from us if you are building a security career on this work.
What we commit to
- Acknowledge your report within two business days, from a person and not an autoresponder.
- Tell you within ten business days whether we are treating it as a vulnerability, and why.
- Keep you updated while it is open, and tell you the day the fix ships.
- Credit you on this page by whatever name you choose, or leave you out of it entirely.
- Never pursue legal action over research that follows this policy, and say so in writing if you want it in writing.
What we ask of you
- Give us enough to reproduce it: the URL, the steps, and what you saw.
- Use the least intrusive test that proves the point, and stop as soon as it is proven.
- Leave other people's data alone. If you reach it by accident, stop and tell us what you saw.
- Do not degrade the service: no automated flooding, no denial of service, no spam.
- Give us time to fix it before you publish. Ninety days, or sooner if we are done sooner.
Research that follows this policy is authorised research. We will not report it, and we will not treat it as a breach of our terms. If a third party brings a claim about work you did within this policy, tell us and we will make our position clear to them.
How to report
Five steps, and the first one is the one that matters.
Most reports that stall do so because they cannot be reproduced. Everything below is aimed at that.
- 01
Write it up
One email with the affected URL or system, the steps to reproduce, what you expected and what actually happened. A short screen recording is worth several paragraphs. Attach proof-of-concept code rather than pasting it inline.
- 02
Send it to us
Email the security address below. Put the affected system in the subject line so it gets to the right person on the first read rather than the second.
- 03
We confirm and triage
You get a human acknowledgement within two business days. We reproduce it, rate it, and tell you what we found, including when we disagree with your severity, and why.
- 04
We fix, you verify
You get the fix to check before we close the report. If our fix does not hold, say so and it goes back to the top of the queue.
- 05
Credit and publication
Once it is closed we add it to the ledger on this page under your name, your handle, or not at all. Publish your own write-up whenever you like after that.
Send it here
[email protected]- First reply in 48 hours
- Business days, from the person who will handle it.
- Publish after 90 days
- Or as soon as it is fixed, whichever comes first.
Machine-readable version of this policy: /.well-known/security.txt
Scope
What counts, and what does not.
Out of scope does not mean uninteresting. It means we will not treat it as a vulnerability report, and it will not appear on the ledger.
In scope
- encryptbytes.com and everything under it
- The admin and client portals we operate
- Systems we host on a client's behalf, and we will route the report
- Software we wrote and still maintain
Out of scope
- Anything that degrades service for other people
- Social engineering of our staff, clients or suppliers
- Physical access attempts at our office or a client site
- Scanner output with no demonstrated impact
- Missing headers or best-practice findings with no exploit path
Hall of fame
Everyone who told us something we needed to know.
Every bug bounty report we have closed, fixed and credited. Dates are the day the report arrived and the day the fix went live.
- 1
- Reports published
- 1
- Researchers credited
- 1
- Fixed or mitigated
- 1
- Years running
2026
1 report
- mediumFooter
Broken Link Hijacking
Reported by
Arjun J U (LinkedIn)16 Jun16 Jun
Fixed
Questions
The ones people ask before sending.
Do you pay a bounty?
Not at the moment. We credit every researcher who wants to be named on this page, we respond quickly, and we will confirm in writing what you found and when it was fixed, which is what most people need it for.
How long until I hear back?
An acknowledgement within two business days, and a decision on whether we are treating it as a vulnerability within ten. If a fix takes longer than that, we tell you why and give you a date.
Can I publish what I found?
Yes, once it is fixed or ninety days have passed, whichever comes first. Tell us the date you intend to publish and we will work to it. If we need longer we will ask rather than assume.
What is out of scope?
Anything that degrades service for other people, social engineering of our staff or clients, physical attacks, and reports that are only the output of an automated scanner with no demonstrated impact. Findings on a client system we host should still come to us, and we will route them.
Not a security report?
If it is a business problem rather than a bug, start here.
The same team that fixes what you found also builds the systems. Tell us what needs to change and you get a scope back within one business day.
Bug bounty and security reports go to [email protected], not to this form.