Reporting

Vulnerability Title	Including vulnerability type, affected domain/parameter/endpoint, impact etc.
CWE & CVSS score	For communicating the characteristics and severity of the vulnerability.
Vulnerability Description	Better understanding of the vulnerability cause.
Proof of Concept (POC)	Steps to reproduce exploiting the identified vulnerability clearly and concisely.
Impact	Elaborate more on what an attacker can achieve by fully exploiting the vulnerability. Business impact and maximum damage should be included in the impact statement.
Remediation	Optional in bug bounty programs, but good to have.

Why CWE & CVSS

MITRE describes Common Weaknesses Enumeration (CWE) as a community-developed list of software and hardware weakness types. It serves as a common language, a measuring stick for security tools, and as a baseline for weakness identification, mitigation, and prevention efforts. In the case of a vulnerability chain, choose a CWE related to the initial vulnerability.

Using CVSS Calculator

Common Vulnerability Scoring System Version 3.1 CalculatorFIRST — Forum of Incident Response and Security Teams

Attack Vector

Shows how the vulnerability can be exploited.

• Network (N): Attackers can only exploit this vulnerability through the network layer (remotely exploitable).

• Adjacent (A): Attackers can exploit this vulnerability only if they reside in the same physical or logical network (secure VPN included).

• Local (L): Attackers can exploit this vulnerability only by accessing the target system locally (e.g., keyboard, terminal, etc.) or remotely (e.g., SSH) or through user interaction.

• Physical (P): Attackers can exploit this vulnerability through physical interaction/manipulation.

Attack Complexity

Depicts the conditions beyond the attackers' control and must be present to exploit the vulnerability successfully.

• Low (L): No special preparations should take place to exploit the vulnerability successfully. The attackers can exploit the vulnerability repeatedly without any issue.

• High (H): Special preparations and information gathering should take place to exploit the vulnerability successfully.

Privileges Required

Show the level of privileges the attacker must have to exploit the vulnerability successfully.

• None (N): No special access related to settings or files is required to exploit the vulnerability successfully. The vulnerability can be exploited from an unauthorized perspective.

• Low (L): Attackers should possess standard user privileges to exploit the vulnerability successfully. The exploitation in this case usually affects files and settings owned by a user or non-sensitive assets.

• High (H): Attackers should possess admin-level privileges to exploit the vulnerability successfully. The exploitation in this case usually affects the entire vulnerable system.

User Interaction

Shows if attackers can successfully exploit the vulnerability on their own or user interaction is required.

• None (N): Attackers can successfully exploit the vulnerability independently.

• Required (R): A user should take some action before the attackers can successfully exploit the vulnerability.

Scope

Shows if successful exploitation of the vulnerability can affect components other than the affected one.

• Unchanged (U): Successful exploitation of the vulnerability affects the vulnerable component or affects resources managed by the same security authority.

• Changed (C): Successful exploitation of the vulnerability can affect components other than the affected one or resources beyond the scope of the affected component's security authority.

Confidentiality

Shows how much the vulnerable component's confidentiality is affected upon successfully exploiting the vulnerability. Confidentiality limits information access and disclosure to authorized users only and prevents unauthorized users from accessing information.

• None (N): The confidentiality of the vulnerable component does not get impacted.

• Low (L): The vulnerable component will experience some loss of confidentiality upon successful exploitation of the vulnerability. In this case, the attackers do not have control over what information is obtained.

• High (H): The vulnerable component will experience total (or serious) loss of confidentiality upon successfully exploiting the vulnerability. In this case, the attackers have total (or some) control over what information is obtained.

Integrity

Shows how much the vulnerable component's integrity is affected upon successfully exploiting the vulnerability. Integrity refers to the trustworthiness and veracity of information.

• None (N): The integrity of the vulnerable component does not get impacted.

• Low (L): Attackers can modify data in a limited manner on the vulnerable component upon successfully exploiting the vulnerability. Attackers do not have control over the consequence of a modification, and the vulnerable component does not get seriously affected in this case.

• High (H): Attackers can modify all or critical data on the vulnerable component upon successfully exploiting the vulnerability. Attackers have control over the consequence of a modification, and the vulnerable component will experience a total loss of integrity.

Availability

Shows how much the vulnerable component's availability is affected upon successfully exploiting the vulnerability. Availability refers to the accessibility of information resources in terms of network bandwidth, disk space, processor cycles, etc.

• None (N): The availability of the vulnerable component does not get impacted.

• Low (L): The vulnerable component will experience some loss of availability upon successfully exploiting the vulnerability. The attacker does not have complete control over the vulnerable component's availability and cannot deny the service to users, and performance is just reduced.

• High (H): The vulnerable component will experience total (or severe) availability loss upon successfully exploiting the vulnerability. The attacker has complete (or significant) control over the vulnerable component's availability and can deny the service to users. Performance is significantly reduced.

Example 1: Reporting Stored XSS

---

Title: Stored Cross-Site Scripting (XSS) in X Admin Panel

CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')

CVSS 3.1 Score: 5.5 (Medium)

Description: During our testing activities, we identified that the "X for administrators" web application is vulnerable to stored cross-site scripting (XSS) attacks due to inadequate sanitization of user-supplied data. Specifically, the file uploading mechanism at "Admin Info" -> "Secure Data Transfer" -> "Load of Data" utilizes a value obtained from user input, specifically the uploaded file's filename, which is not only directly reflected back to the user’s browser but is also stored into the web application’s database. However, this value does not appear to be adequately sanitized. It, therefore, results in the application being vulnerable to reflected and stored cross-site scripting (XSS) attacks since JavaScript code can be entered in the filename field.

Impact: Cross-Site Scripting issues occur when an application uses untrusted data supplied by offensive users in a web browser without sufficient prior validation or escaping. A potential attacker can embed untrusted code within a client-side script to be executed by the browser while interpreting the page. Attackers utilize XSS vulnerabilities to execute scripts in a legitimate user's browser leading to user credentials theft, session hijacking, website defacement, or redirection to malicious sites. Anyone that can send data to the system, including administrators, are possible candidates for performing XSS attacks against the vulnerable application. This issue introduces a significant risk since the vulnerability resides in the "X for administrators” web application, and the uploaded files are visible and accessible by every administrator. Consequently, any administrator can be a possible target of a Cross-Site Scripting attack.

POC:

Step 1: A malicious administrator could leverage the fact that the filename value is reflected back to the browser and stored in the web application’s database to perform cross-site scripting attacks against other administrators by uploading a file containing malicious JavaScript code into its filename. The attack is feasible because administrators can view all uploaded files regardless of the uploader. Specifically, we named the file, as follows, using a Linux machine.

// sample code
"><svg onload = alert(document.cookie)>.docx

CVSS Score Breakdown

Attack Vector:	Network - The attack can be mounted over the internet.
Attack Complexity:	Low - All the attacker (malicious admin) has to do is specify the XSS payload eventually stored in the database.
Privileges Required:	High - Only someone with admin-level privileges can access the admin panel.
User Interaction:	None - Other admins will be affected simply by browsing a specific (but regularly visited) page within the admin panel.
Scope:	Changed - Since the vulnerable component is the webserver and the impacted component is the browser
Confidentiality:	Low - Access to DOM was possible
Integrity:	Low - Through XSS, we can slightly affect the integrity of an application
Availability:	None - We cannot deny the service through XSS