Jun 24, 2019 3 min read

Tips For Information to Include in a Vulnerability Disclosure

Post to give recommendations about what information to include when disclosing a vulnerability and why it is important to do so.

Tips For Information to Include in a Vulnerability Disclosure

So all too often I see a vulnerability being disclosed, yet details about the vulnerability are vague. This makes trying to evaluate the risk with the vulnerability poses to be very difficult. The purpose of this post is to hopefully help provide some pointers which would hopefully help aid giving the appropriate information required when disclosing a vulnerability.

Detailed vs Vague

There may be times where you certainly would not want to include detailed information about the vulnerability. The most likely case is where the vulnerability is a 0-day and there isn't yet a likely fix. In this case you want to keep the details vague so that potential attackers cannot learn of these details and then actively exploit the vulnerability. Similarly there may be times where the vulnerability may be so critical you may wish to keep the details vague for similar reasons. However in order for users of the service or product, it is still important to have some basic understanding at to how the vulnerability could affect them. This is to allow them to try evaluate the potential risk which is poses to them.

In cases where there is no explicit need to keep details vague, it is best to include as much detail as possible such as, including perhaps how to reproduce the vulnerability, or at least confirm the vulnerability. The more information which you give, the better that users can accurately measure the potential risk which the vulnerability poses to them.

However, in both cases you should at least have the following:

  • Products/Services affected
  • Severity rating (typically Critical, High, Medium and Low)
  • CVSS Vector (more on this below)
  • Recommended steps to take to resolve or mitigate the vulnerability


Common Vulnerability Scoring System (CVSS) is an industry standard which attempts to rate or score a vulnerability. While not perfect, and it does have its downfalls, it's the best tool we have the moment. Also this is used to rate vulnerabilities, and is not well suited to all security findings, such as findings where a product or service does not follow best security practices. The basic principle is that it uses a set of principles to try formulate some score which could be equated to the risk which the vulnerability poses (the severity of the vulnerability). First have a more detailed description on their site.

This can at times be a bit of a hit and miss. Take for instance the Heartbleed vulnerability. This received a CVSS score of 5, which made it a medium severity vulnerability. But as most involved in this industry know this was not quite the case, and it was quite a serious issue. The other issue is that at times some of the scoring can be subjective, and one person's interpretation will differ to another person's interpretation.

However, the most useful piece is the CVSS Vector in my opinion. This can help give information about the vulnerability without giving many details about the vulnerability. This helps especially in the cases where you may want to keep the details about the vulnerability vague. Yet these details will still help users gauge what risk the vulnerability poses to them such as:

  • Is this exploitable remotely?
  • Does it require any authentication to exploit?
  • Does it result in the leakage of data?
  • Does it result in the altering/tampering of data?
  • Is this a DOS type vuln?
  • How easy is it to exploit?

All of these are the type of questions which one tends to ask when trying to gauge the risk which a vulnerability poses, and hence allow them to rate the risk for themselves. Also it is worth noting that amount of risk which a vulnerability poses to one person or organisation may be completely different to another person or organisation. People and organisations have different appetites for risk as well as different circumstances. For example, say there's a critical for a web server vulnerability. Company A has this installed on a server which is Internet facing. This is a high risk to that company. Then we have company B, they only have this web server installed on their internal network. The risk which the same vulnerability poses is thus likely to be lower for company B, than company A.


Including as much information as feasible and possible given the circumstances is really important. This helps those who are ultimately the ones who are going to suffer as a result of the vulnerability to be able to make informed decisions and calculations on the risk which the vulnerability poses to them. Things like the CVSS vector can be a very useful too for this.

Sean Wright
Sean Wright
Experienced application security engineer with an origin as a software developer. Primarily focused on web-based application security with a special interest in TLS and supply chain related subjects.
Great! You’ve successfully signed up.
Welcome back! You've successfully signed in.
You've successfully subscribed to Sean Wright.
Your link has expired.
Success! Check your email for magic link to sign-in.
Success! Your billing info has been updated.
Your billing was not updated.