Crafting Actionable Vulnerability Reports

Hello! Welcome to your next lesson.

In our last session, we covered how to interpret bug bounty program policies and scopes, which is the essential first step in any engagement. You learned that these policies are your Rules of Engagement, defining the legal and technical boundaries of your work.

Now, imagine you've followed those rules, selected a target, and found a valid, in-scope vulnerability. What's next? This is where your communication skills become just as important as your technical skills. A groundbreaking discovery can be completely overlooked if it's poorly reported.

Today's lesson addresses this critical final step. Our learning outcome is to write a clear and actionable vulnerability report that includes a description, impact, and remediation steps. Mastering this skill will build your reputation, increase your payouts, and open doors to exclusive, private programs.

1. The Anatomy of a Professional Vulnerability Report

A high-quality report is your primary deliverable. It's the product that a client or bug bounty program is paying for. While the format can vary slightly between platforms and pentest engagements, all great reports share a common logical structure designed for clarity and action.

The ultimate goal is to provide all the necessary information for someone on the security team—who may be tired and reviewing reports at 3 AM—to understand, reproduce, and fix the issue without needing to ask you for clarification.

To get a concise overview of the essential components, let's start with a video from professional bug bounty hunter NahamSec.

These five components are the pillars of a strong report. Let's explore each one in more detail, drawing from best practices across the industry.

2. A Deep Dive into Each Report Component

For a more structured and detailed perspective, we'll consult a comprehensive article from the Cobalt pentesting platform. It reinforces NahamSec's points and provides additional valuable context.

Now, let's synthesize the key takeaways from these resources for each component.

A. Title

The title is your first impression. It should be specific and informative, not generic or sensational.

• Bad: CRITICAL - XSS on your program
• Good: Stored Cross-Site Scripting (XSS) in User Profile Bio Field leading to Account Takeover

The good title tells the triage team the vulnerability type (Stored XSS), the location (User Profile Bio), and the potential impact (Account Takeover) immediately.

B. Summary / Description

This section provides a brief, clear explanation of the vulnerability. It should explain what the vulnerability is in plain language. For context, it's highly recommended to reference industry standards like the OWASP Top 10 or the specific Common Weakness Enumeration (CWE) number.

C. Proof of Concept (PoC)

This is the heart of your report. It must contain a precise, step-by-step guide to reproduce the vulnerability. Assume the reader knows nothing about your process.

Your PoC should include:

• Clear Steps: Numbered instructions from start to finish (e.g., 1. Navigate to https://example.com/profile, 2. Click 'Edit Bio', etc.).
• Payloads: The exact input you used (e.g., <script>alert(document.domain)</script>).
• Evidence: Screenshots or, for more complex attacks, a video recording showing the exploit in action. A video is particularly useful for demonstrating chained exploits or race conditions.
• Technical Details: For web vulnerabilities, including the full HTTP request and response (using code blocks) is standard practice. Burp Suite makes this easy to copy.

D. Impact

This is where you explain why the vulnerability matters. You must connect the technical flaw to a tangible business risk. Don't assume the reader understands the implications.

• Be Honest and Specific: Don't exaggerate. A low-impact bug presented as critical will damage your credibility. Instead of saying "An attacker can steal cookies," explain what they can do with those cookies in the context of this specific application. For example: "By stealing the admin user's session cookie, an attacker can gain full administrative access to the backend, allowing them to view, modify, and delete all user data."
• Consider the "CIA Triad": Frame the impact in terms of Confidentiality (unauthorized data access), Integrity (unauthorized data modification), and Availability (disrupting service).

E. Remediation

A good report doesn't just point out problems; it offers solutions. Your remediation advice should be actionable and specific.

• Go Beyond Generic Advice: Instead of just saying "Sanitize user input," provide a code-level example if possible. Given your Computer Science background, this is an area where you can provide significant value. For instance, show a C# or Python snippet demonstrating how to use parameterized queries to prevent SQL Injection.
• Address the Root Cause: Your primary recommendation should fix the core issue, not just patch a symptom. For example, while a WAF rule might mitigate an SQLi, the correct fix is to implement parameterized queries in the application code.

3. Practical Example: Writing a Report from Scratch

Theory is one thing, but seeing it in practice is another. Let's watch a detailed walkthrough of a report being written on a real bug bounty platform.

Notice the use of Markdown for formatting. Most bug bounty platforms and reporting tools use it to structure reports with headings, links, code blocks, and images.

To streamline this process, many hunters use templates. There are even tools and repositories dedicated to this.

4. Adapting Your Report: Bug Bounty vs. Penetration Test

Your career goals include both bug bounty hunting and penetration testing. While the core components of a vulnerability write-up are the same, the overall report structure differs.

Here's the key difference:

• Bug Bounty Report:

  • Focus: Documents a single vulnerability.
  • Audience: Primarily technical (developers, security engineers).
  • Format: More informal, often submitted through a web form. The main goal is rapid, clear reproduction.

• Penetration Test Report:

  • Focus: A formal document detailing all findings from an engagement.
  • Audience: Broader, including business executives, security managers, and technical teams.
  • Format: Includes an Executive Summary written in non-technical language for business stakeholders, a narrative of the test methodology, and then individual vulnerability write-ups. It provides a holistic view of the target's security posture.

Understanding this distinction is vital as you navigate both fields.

Test your understanding!

You've discovered an Insecure Direct Object Reference (IDOR) vulnerability. By changing the id parameter in the URL https://example.com/orders?id=123 to id=124, you can view another user's order details.

Based on the five core components we discussed, draft a brief outline for each section of a bug bounty report for this vulnerability.

Show answer

• Title: IDOR in id parameter allows unauthorized access to other users' order details.
• Summary: An IDOR vulnerability exists in the /orders endpoint. The application fails to verify that the logged-in user is authorized to view the order associated with the id parameter, allowing any authenticated user to view any other user's order by manipulating this parameter. This is a form of Broken Access Control (OWASP A01:2021).
• Proof of Concept (PoC):
  1. Log in to the application with User A's account.
  2. Navigate to your order history and click on an order, which takes you to https://example.com/orders?id=123.
  3. Observe that you can see User A's order details.
  4. Modify the URL in your browser to https://example.com/orders?id=124 (an ID belonging to User B).
  5. Observe that the order details for User B are displayed, confirming the vulnerability.
• Impact: This vulnerability breaks data confidentiality. An attacker can enumerate order IDs to systematically access and exfiltrate sensitive customer information from all orders on the platform, including names, shipping addresses, and purchase histories. This could lead to significant privacy violations, reputational damage, and potential financial loss.
• Remediation: On the server-side, before rendering an order's details, implement a check to verify that the userID associated with the session of the currently logged-in user matches the userID associated with the order ID requested in the id parameter. If they do not match, return a 403 Forbidden error.

Conclusion

Writing a high-quality report is a skill that separates good hackers from great ones. It is your primary means of communicating value, building trust, and ensuring that the vulnerabilities you find actually get fixed.

Key Takeaways:

• The 5 Pillars: Every report needs a descriptive Title, a clear Summary, a reproducible Proof of Concept, a compelling Impact statement, and actionable Remediation advice.
• Reproducibility is King: Your PoC must be so clear that anyone can follow it. Provide steps, payloads, and evidence (screenshots/videos).
• Contextualize the Impact: Explain the business risk. How does this vulnerability affect the company's data, users, or reputation?
• Know Your Audience: A quick bug bounty submission is different from a formal pentest report, which requires an Executive Summary for business leaders.

Next Lesson Preview:

In this lesson, we discussed assessing the "criticality" or "impact" of a bug. But how do we standardize this? How do we assign a numerical score to a vulnerability? In our next lesson, we will dive into the industry-standard framework for this: the Common Vulnerability Scoring System (CVSS). You will learn how to assign a CVSS score to a vulnerability based on its technical characteristics and impact, a crucial skill for both pentesting and bug bounty reporting.