0x00 How to Structure a Bug Bounty Report for Maximum Clarity
A well-structured report is crucial for conveying your findings clearly and efficiently. A typical bug bounty report should include the following sections:
Title: A concise and descriptive title that accurately reflects the vulnerability. For example, "Reflected XSS on User Profile Page" or "SQL Injection in Product Search Functionality."
Executive Summary: A brief overview of the vulnerability, its potential impact, and the steps to reproduce it. This section should be easily understandable by both technical and non-technical audiences.
Vulnerability Details: A detailed explanation of the vulnerability.
Steps to Reproduce: A clear and concise step-by-step guide on how to reproduce the vulnerability. This should be easy to follow and should not require any specialized knowledge or tools.
Proof of Concept (PoC): A working demonstration of the vulnerability. This can be a screenshot, a video, or a code snippet that shows the vulnerability being exploited.
Impact: A detailed explanation of the potential impact of the vulnerability. This should include both technical and business impacts.
Remediation Recommendations: Specific and actionable recommendations on how to fix the vulnerability.
References: Links to relevant resources, such as OWASP documentation, CVE entries, or other bug bounty reports.
0x01 Documenting Vulnerabilities with Clear Attack Narratives
When documenting a vulnerability, be precise in your language and avoid ambiguity, making sure to clearly identify the vulnerable components and the attack vectors. Provide context by explaining the environment in which the vulnerability exists, including details about the application, its setup, and the roles of the users involved.
Show how data flows through the application and demonstrate how the flaw allows an attacker to manipulate that flow. To strengthen your report, include screenshots and videos that visually highlight the vulnerability and its impact, as well as relevant code snippets to illustrate the technical details. Finally, explain the exploitation process step by step, outlining the tools and techniques used so the reader can fully understand how the vulnerability can be leveraged.
0x02 Demonstrating Business Impact in Bug Bounty Reports
Highlighting the potential business impact of a vulnerability is crucial for convincing the bug bounty program that it is worth fixing. Consider the following when demonstrating business value:
Identify Potential Risks: Explain the potential risks associated with the vulnerability, such as data breaches, financial losses, reputational damage, and legal liabilities.
Quantify the Impact: Whenever possible, quantify the potential impact of the vulnerability. For example, estimate the number of users that could be affected, the amount of data that could be compromised, or the potential financial losses.
Relate to Business Objectives: Explain how the vulnerability could impact the organization's business objectives. For example, could it disrupt critical business processes, damage customer relationships, or violate regulatory requirements?
Consider the Attack Surface: Analyze the attack surface and identify the potential attack vectors that could be used to exploit the vulnerability.
Prioritize Vulnerabilities: Help the organization prioritize vulnerabilities by ranking them based on their potential impact and likelihood of exploitation.
0x03 Writing Clean Proof of Concept (PoC) Exploits
A clean and concise proof of concept (PoC) is essential for demonstrating the validity of your findings. When writing a proof of concept (PoC), keep it as simple as possible while still clearly demonstrating the vulnerability, avoiding unnecessary complexity. Focus on the core issue and leave out extraneous details so the problem remains the centerpiece. To make reproduction easy, minimize dependencies and provide clear, concise instructions on how to run the PoC. Always include the expected results so others know what to look for.
Before sharing, test the PoC thoroughly to confirm it works as intended. Be careful to avoid destructive actions, such as deleting data or altering system configurations, and make sure your approach aligns with ethical hacking principles, avoiding any violations of laws or regulations.
0x04 Handling Program Pushback and Report Disputes
It's not uncommon to encounter pushback from bug bounty programs. When dealing with a program’s assessment, it’s important to stay calm and professional, even if you disagree with their conclusions. Start by carefully reviewing the program’s rules and guidelines to make sure your report fully complies with them. If the program requests additional information, provide it promptly and accurately.
Take the time to clearly explain your reasoning and include evidence to support your claims. Be open to discussion, listen to the program’s perspective, and engage constructively. If the issue remains unresolved, consider escalating it to a higher authority. Regardless of the outcome, use the experience as a learning opportunity to improve the quality of your future bug bounty reports.
0x05 HackerOne Case Study:TE.CL Desync
Our anchor case: a disclosed HackerOne report against labs.data.gov (GSA Bounty). The researcher demonstrated a TE.CL desync (front end honored Transfer-Encoding, back end trusted Content-Length), proved impact safely, paused once collateral risk appeared, and still earned a $750 bounty.
This is what “good” looks like.
0x06 Root Cause Analysis: TE.CL Desync Vulnerability Explained
When a front-end proxy and a back-end server parse the same request differently, you can “splice” a second request into the TCP stream. In this case, the front end treated the request body as chunked (Transfer-Encoding: chunked), while the back end relied on a fixed body size (Content-Length). That mismatch let the attacker smuggle a second, attacker-controlled request that the back end would process as if it were the victim’s next request.
If you want a refresher on the families and how they break (CL.TE, TE.CL, TE.TE), Take a look at the ToxSec guide to HTTP request smuggling.
0x07 Evidence Collection in Bug Bounty Reports (Impact Without Overreach)
The researcher used Turbo Intruder to queue:
a crafted desync request that embeds a benign secondary request to a clearly nonexistent path (e.g.,
/hopefully404), thena short burst of normal requests to increase the odds of catching the poisoned socket.
That small burst raises detection reliability without hammering the target. The point wasn’t to flood. They just needed to catch one poisoned response as evidence.
The Signals
Deterministic marker: the smuggled request targeted a path that should 404. Seeing a victim request receive that 404 is a clean confirmation you’ve altered someone else’s response path.
Reflections everywhere: the attacker’s Collaborator hostname surfaced in the victim response across
<link>, JSON-LD, and other assets—clear proof of asset injection potential.Analyst confirmation: the program’s analyst initially saw WAF-like timeouts on probes, then reproduced and triaged the behavior—useful reminder that modern infrastructure may partially deflect probes while still being vulnerable.
The restraint
Once a real user from Los Angeles showed up in Collaborator evidence, the researcher stopped escalating. They had enough proof. That single decision often separates a clean triage from a bad day.
0x08 Timeline of a Bug Bounty Report: From Submission to Disclosure
2019-10-31 — Report submitted with PoC, screenshots, Collaborator evidence.
2019-11-01 — Analyst observes timeouts consistent with WAF behavior, requests clarity, then confirms and triages.
2019-11-14 — $750 bounty awarded (High).
2020-04-20 — Resolved.
2020-05-13 — Disclosed.
This arc is common: initial probe weirdness (WAF), analyst validation, partial mitigations, then structural fixes. Even if exploitation is unreliable (desyncs can be flaky), programs treat this as High: the path from parser mismatch → socket poisoning → user impact is real, and the consequences are serious. In this case, GSA confirmed the behavior, fixed a host-injection vector quickly, and worked with a service provider on the broader desync/WAF behavior.
0x09 Bug Bounty Reporting Best Practices: What to Copy and What to Avoid
What this report did right (copy this)
Lead with the cause. The very first lines explain the parser disagreement (TE vs CL). No mystery, no buzzwords. Analysts triage faster when they see the root cause up front.
Bounded PoC. A desync that targets a nonexistent path + a small request burst = reliable signal with minimal blast radius.
Concrete evidence. Screenshots + reflected attacker host in multiple critical assets + Collaborator hits.
Ethical stopping point. Collateral risk observed → stop. Document it; don’t keep pressing.
Actionable impact. They spelled out what an attacker could do via asset control and cookie theft hypotheses, while labeling unverified parts as such.
What to avoid (they avoided it)
Over-claiming reliability. Don’t position desyncs as 100% weaponized if you have 20% success. Say it.
Risky payloads “for proof.” You don’t need aggressive JS beacons or destructive routes. Use clean 404 markers and asset reflections.
Opaque steps. If an analyst can’t replay your flow with their own tooling (Burp/Turbo Intruder), you’ll lose time in back-and-forth.
0x0B Debrief — Traits of a Strong Bug Bounty Report
Strong bug bounty reports share the same traits: clear structure, thorough documentation, and a focus on business impact. A good report doesn’t just show a payload—it explains the context, demonstrates risk, and offers a path to remediation. Clean proof-of-concepts make validation easy, while professional communication helps when programs push back.
The hunters who succeed consistently are the ones who treat reporting as part of the craft: precise, reproducible, and grounded in the value it brings to the organization.
If your new to the process of bug bounty, check out the introduction to bug bounty guide from ToxSec here.