Disclosing Vulnerabilities, Properly - Part 1
March 30, 2020
Note: This article is evergreen. This means it will be updated as more information becomes available, to ensure you get the best information possible.

People often contact me and ask me to help them reach specific businesses or governments to help them disclose vulnerabilities. This is not a service that I offer; people seem to think that I will know what to do and be willing to help. It seems that perhaps writing a blog post is a good way to share what you should do if you are aware of a vulnerability and are uncertain of how to get the information to the right people, securely.


When you report a vulnerability, the first thing people will want to know from you is how you found it. Whether you are a security researcher, a regular user who  pressed the 'next button' one too many times, or someone who was doing something less-than-savoury; you will be asked to explain yourself. If at all possible, document how you found it, to show that you were within the confines of the law. Assuming that the way you found the vulnerability was not in violation of your country's laws or the user agreement, you will also want to write up instructions that make the vulnerability reproducible, and also explain the risk (if applicable/as best you can).

If the vulnerability you found is in a product, look on the webpage for the product or the company's webpage to see if they have either 1) a bug bounty program or 2) a responsible disclosure program. If they have either of those two programs, follow the instructions and submit. It is very important that you submit the information in the way they ask for it (including ensuring the information you send is sent in a secure way), and that you are patient for their response.

Note: if you are submitting to a bug bounty program make sure you are submitting something that is 'in scope' of the program.  If what you want to report is out of scope you need to contact them to explain the issue and ask how they would like you to report it. If you report something that is out of scope they may ignore you, and then you are back to square one.

This image has nothing to do with reporting vulnerabilities, but sometimes a blog post needs more images.

If the company doesn't have any programs for disclosing the security problem, try to contact the security team. If it's a large company, you might be able to find them on social media (for instance, I needed to contact the GitHub Security Team, I tweeted that I needed to reach them, and 5 minutes later I was talking to one of them). If you can't find them on the website or social media, try sending an email to "[email protected]", and as a last resort "[email protected]". In this email it is important to explain that you need to disclosure a vulnerability to them, and you want to do it in a secure way, and ask them how they would like you to send them the information.

  • Do not demand or ask for money in exchange for the vulnerability. That is extortion, and generally illegal. Plus, it will start the conversation on the wrong foot.
  • Do not send in account takeovers. Many vulnerability programs receive submissions like this and it is never in scope for you to break into one of their customer's real accounts. If there is a vulnerability in the way accounts are managed, send in that, not proof that you have broken the user agreement (and likely also the law).
  • Explain the issue as clearly as you possibly can; remember, the person reading this likely has almost no context, which you may have been researching this for months.
  • Make sure you follow their preference for how to report it and how to send the information to them.

What do you do if the issue you found is in many products, not just one?

In the tweet at the start of this article, I wanted to know how to report a pattern of vulnerabilities, rather than a specific issue in a specific product. If a vulnerability is in all of a certain type of hardware, how does one report that?  It turns out that the correct protocol for many countries is to report it to the CIRT (Cyber Incident Response Team) for your government. In the case of the tweet above, all of the research was done by Canadians, at a Canadian University, and therefore it makes sense to report it to the Canadian Centre for Cyber Security (previously known as GC-CIRT) (Canadian Goverment CIRT). If your government does not have a CIRT, and you feel comfortable reporting to an American organization, they accept vulnerabilities from all over at CERT Coordination Center at the Carnegie Mellon University Software Engineering Institute. They are well respected, and quite frankly, extremely organized and ready for such a situation (not all CIRT organizations are).

Another option is to contact https://disclose.io. A group dedicated to ensure safe harbour of security researchers. This would be used if you 1) have a bad experience when contacting your Goverment's CIRT, or 2) if you just don't trust them.

What do you do if the company ignores you? Or denies that it is a problem? Or threatens to sue? Read more in Part 2 of this article.

No comments yet
Write a comment...

ALL New Blogs, Videos, Articles and more! (does not include courses)

$7 / month
$70 / year (save 17%)
Includes access to 4 products:
Get access