Write

Write a triager-grade report

Apply this when the hunter is writing up a confirmed finding. Your job is to help them shape the draft — propose prose from their facts, offer alternatives for any section, push back on missing content.

Structure follows YesWeHack's official guidance (https://www.yeswehack.com/fr/learn-bug-bounty/write-effective-bug-bounty-reports). Platform-level fields (title, asset, severity, CVSS) are filled in via the YesWeHack submission form, not the markdown body — see end of this skill.

Required body sections (in order)

1. Description
2. Vulnerability discovery
3. Proof of Concept (PoC)
4. Exploitation
5. Impact
6. Remediation (optional)
7. References (optional)

If a required section is missing, ask the hunter for it before continuing.

1. Description

• 1-3 sentences. What the bug is, factual and specific.
• Do not put a CWE ID here. YesWeHack renders the CWE from the form field automatically — repeating it in the body is noise.
• No multi-paragraph OWASP intro, no "what is XSS" boilerplate.

Good: Reflected XSS in /search via the q parameter. The parameter is echoed unescaped into the HTML response body. Bad: 5-line definition of what XSS is; a (CWE-79) tag inline.

2. Vulnerability discovery

• Your testing narrative — what you tried, what you noticed, what made you dig in.
• Lab-notes style. Dead ends and friction are credible signals; keep them.
• Brief: a paragraph is usually enough.

Good: "Fuzzing the search endpoint with a custom wordlist, I noticed <script> was filtered but <svg/onload=...> wasn't. After confirming reflection context was the HTML body, I tested alert(document.domain) to verify same-origin execution." Bad: a polished narrative with no failed attempts.

3. Proof of Concept (PoC)

• Raw HTTP request/response — preferred. Triager pastes into Repeater.
• curl — acceptable. Complete: headers, cookies, body.
• Screenshot — when visual proof matters (alert dialog, UI rendering). Always paired with the request that produced it.
• Video — for multi-step flows or timing-dependent bugs.
• Strip session tokens, real user data (PII), unrelated headers. Use [REDACTED] where you removed something. Sanitize; don't fabricate.

Include only the requests that are strictly necessary to reproduce. A triager wants the minimal path, not your whole session. Cut recon noise, unrelated calls, and duplicate attempts.

Don't wrap the PoC in a ready-made script unless it's genuinely needed (real multi-step chains, timing/race windows, thousands of iterations). For a bug provable in one or two requests, a raw request beats a Python script every time — the triager can replay it directly without reading, trusting, or running your code. Reach for a script only when raw requests can't express the bug.

A PoC is valid only if a triager with zero prior context can replay it from scratch.

4. Exploitation

• Numbered steps, one action per step.
• Atomic: each step is a single observable action a triager performs verbatim, no inference required.
• State preconditions upfront: anonymous or authenticated? which role? required victim interaction? required browser/environment?
• Include expected vs actual at the step where the bug manifests.
• For complex bugs, a script is acceptable as a supporting artifact (per YesWeHack guidance) — but the markdown still needs atomic steps.

Good:

Preconditions: standard logged-in user (any role), no special
privileges. Tested in Chrome 132.

1. Send GET https://target.example.com/search?q=<svg/onload=alert(1)>
2. Observe: alert(1) fires in the response page.
   Expected: the payload HTML-encoded in the response.

Bad: Go to the search page and trigger the XSS.

5. Impact

• Only what was demonstrated. Never theoretical.
• Bottom-up from the PoC: "I executed X, observed Y at Z."
• No "could", "may", "potentially", "with the right conditions".
• If only reflection was proven, don't claim ATO.

Good: Arbitrary JS execution in the victim's browser in the target.example.com origin. I demonstrated reading document.cookie and exfiltrating it to a controlled endpoint (PoC step 4). Bad: Could lead to full account takeover, session hijacking, and exfiltration of sensitive user data.

6. Remediation (optional)

Include only if:

• You know the target's stack and have framework-specific advice, OR
• The fix is concrete and trivially correct (e.g., "HTML-encode the q parameter before reflection in /search/index.html").

Generic mitigations ("validate user input", "use parameterized queries", "follow OWASP guidelines") add zero value. Omit rather than padding.