How to write a Detailed Vulnerability Report

As a security researcher or penetration tester, it is crucial to recognize the significance of a well-written and detailed vulnerability report. This report serves as the main method of communication with the security or developer team so it’s should have all the necessary details. A comprehensive vulnerability report provides important information to the security team, helping them understand the severity of the vulnerability and the necessary steps to fix it. In this article, we will discuss the essential parts of an effective vulnerability report and share valuable tips and tricks to improve its quality.

This is a general report format which could be used to report any discovered vulnerability on Bug Bounty Platforms or within Responsible Disclosure Programs.

Vulnerability Name

The essential part of a great vulnerability report would always be a descriptive title/vulnerability name, as this would be the first part checked by the security team. Therefore, always try to keep the title detailed and simple instead of complicated and short. The given example below is an example of bad practice in writing a title:

This title is too vague and does not provide any specific information about the vulnerability. Instead of the this title, you could write something more descriptive and detailed, such as:

This revised title clearly identifies the specific type of vulnerability (Local File Inclusion) and the affected component (Filename parameter on Home Page), providing more valuable information to the security team.

The affected URL/area refers to specific web addresses or sections of a website that have been identified as vulnerable. In this section, you can also mention the form or parameter details that have been identified as vulnerable. For Example:

The Vulnerability Description section should contain an in-depth explanation of the identified vulnerability that is relevant to the particular web application. It is important not to rely solely on general explanations found on the internet. Instead, provide specific details and context about how the vulnerability was discovered, including the methodology, tools, or techniques used, as well as any other relevant technical information. This ensures that the security team receives accurate and tailored information about the discovered vulnerability. The following example is poorly written and does not effectively describe the Vulnerability.

The improved version of this description is given below, with more details that are highly relevant to the web application and the discovered vulnerability.

Severity and Risk Rating are used to assess the impact and potential harm of the vulnerability on the Web Application.

Severity refers to the seriousness or degree of harm that a vulnerability can cause if exploited. It is used to prioritize vulnerabilities based on their potential impact, helping organizations understand the level of risk and urgency in addressing them. Severity ratings assist in making informed decisions regarding vulnerability remediation and risk management strategies.

Risk Rating is a measure that assesses the likelihood and potential impact of a vulnerability being exploited. It helps organizations prioritize vulnerabilities based on their level of risk, allowing them to allocate resources efficiently and address the most critical threats first.

CVE, CWE, and CVSS Score will provide specific identification of vulnerabilities, their associated weakness categories, and a quantitative measure of their severity. This information assists organizations in understanding the nature of vulnerabilities, their potential impact, and the urgency required for their remediation.

CVE (Common Vulnerabilities and Exposures) is a dictionary that provides unique identifiers for publicly known vulnerabilities. It helps in identifying and referencing specific vulnerabilities across different platforms and tools.

CWE (Common Weakness Enumeration) is a list of common software weaknesses or vulnerabilities. It provides a standardized language to describe and categorize different types of vulnerabilities, helping in better understanding and communication.

CVSS (Common Vulnerability Scoring System) Score is a numerical value assigned to a vulnerability to assess its severity and prioritize remediation efforts. CVSS provides a consistent and standardized way of measuring the impact of vulnerabilities based on factors such as exploitability, impact on confidentiality, integrity, and availability.

Vulnerability Class A vulnerability class is a category or group of vulnerabilities that share similar characteristics or exploit methods. It helps to classify and understand different types of security weaknesses in the applicatons.

Impact definec the potential consequences and severity of a vulnerability if being exploited. It assesses the extent of damage or harm that could occur to the system, network, or organization. Impact considers factors such as data loss, unauthorized access, disruption of services, financial losses, reputational damage, and compliance violations. Impact of the vulnerability should be relevant to the particular web application.

Steps to reproduce helps the security team with the specific steps taken during the assessment process. Ensure the steps are detailed enough for another person or security team to follow up and replicate the findings accurately.

Proof of Concept (PoC) refers to the demonstration or evidence that showcases the existence and exploitability of the vulnerability discovered. In the PoCs you should always highlight the vulnerable url and parameter as given in the below example.

Mitigation/Remediation refers to the process of resolving a security vulnerability discovered in the application. It involves taking appropriate actions to address the root cause of the problem, implementing necessary fixes or countermeasures, and ensuring that the affected application is secure and functioning properly. Remediation could consist of general steps according to the vulnerability or could be specific to the application; this depends on the information you have.

In the References section, you can provide external sources that offer supporting information or documentation regarding the identified vulnerability. These references serve as additional resources for understanding the nature of the vulnerabilities, their potential impact, and the recommended remediation steps.

Creating a detailed technical report for a vulnerability can be a challenging task, but such reports are always highly appreciated. As mentioned earlier, this technical report will serve as our primary means of communication with the security team on the other end. Having strong reporting skills alongside technical expertise is always a win-win situation for you. Therefore, make sure your report is as easy to read as possible while including all the required technical details. I have attached a Sample Technical Report Below.

Goodbye Guys!!! We’ll see you in the next blog.

Thank You For Reading…….

Happy Hacking !!!