Why this page exists
We make a living finding vulnerabilities in other people’s products. When one is found in ours we want to hear about it; not wanting to would contradict the whole point of what we do.
This page sets out how to report one to us safely, and what we commit to in return.
In scope
sendthecanary.com and all subdomains.
The customer panel and the API behind it.
The infrastructure of email we send in our own name (SPF, DKIM, DMARC configuration).
Public repositories of our source code, where they exist.
Out of scope
Our customers’ systems. If you found a vulnerability in a customer’s product, report it to that organisation directly, not to us.
Third-party services we use. Report those to the provider concerned; we will help you find the right route if you want.
Social engineering, physical security, and phishing attempts against our staff.
Findings with no demonstrable security impact: missing security headers, exposed but unexploitable version information, raw automated scanner output, and email configuration suggestions beyond SPF and DMARC.
Denial of service and load testing. Please do not.
How to report
Send your report to [email protected].
Encrypt it where you can. Our PGP key is available by sending an empty email with the subject "key" to the same address.
You can write in Turkish or English.
What to include
The affected address, endpoint or component.
The class of vulnerability and the impact you believe it has.
Reproduction steps — detailed enough that we can see it too.
Any screenshots, request and response logs, or proof of concept.
How to reach you, and how you would like to be credited.
Rules we ask you to follow
Work only with your own account or accounts you created for testing.
Do not access other users’ data. If you find you can, stop there, go no further, and say so in your report.
Do not delete, alter or exfiltrate data. Showing that a record exists is enough; downloading its contents is not necessary.
Do not disrupt the service: no load, no brute forcing, no automated scanner at high rates.
Leave no persistent access behind; clean up anything you created for testing.
Do not disclose the vulnerability publicly until we have fixed it and the date we agreed together has arrived.
What we commit to
We acknowledge your report within 2 business days.
We share our first assessment within 10 business days: whether we reproduced it and, if so, what severity we assigned.
We give a status update at least every 15 days while a fix is in progress, and tell you when it is complete.
Where we do not consider a finding valid, we say why in writing. You are welcome to disagree and come back to us.
Our remediation targets
Critical: 7 days. High: 30 days. Medium: 90 days. Low: the next planned release.
Where we are going to miss a target we tell you in advance, with the reason.
Safe harbour
We take no legal action and make no complaint to the authorities against anyone researching in good faith within the rules on this page.
For as long as you follow the rules, we treat your research as authorised access to our systems.
If a third party brings a complaint against you, we will support you in evidencing that you followed the rules.
This safe harbour applies only to systems in scope and only where the rules above are followed.
Public disclosure
You may publish your finding 90 days after the fix is complete.
If you want to publish earlier, talk to us; in most cases we can agree something.
Where a fix takes longer than 90 days, we reassess the timeline with you. We will not ask for an indefinite delay.
When you publish, we ask that you share no customer data, customer names, or any detail belonging to customer systems.
Rewards
We do not currently run a paid bounty programme.
For valid findings not previously reported we credit you by name in our acknowledgements, if you would like that.
For a critical finding we consider recognition separately and will get in touch with you.
Acknowledgements
We credit researchers who report vulnerabilities to us on this page, with their permission.
You may prefer your name, a handle, or nothing at all. Say which in your report.
Scope changes
We update the scope when we bring a new system into production.
If you are not sure whether something is in scope, ask before testing it. Asking is always acceptable.
These documents are published in English and Turkish. In the event of conflict the Turkish text prevails.