Coordinated Disclosure & Retesting

Reporting LOW v1.0.0 updated 2026-07-05

Navigate coordinated disclosure timelines, communicate professionally with triage teams, handle duplicates and escalation, and rigorously retest fixes for bypasses and regressions.

Tools

hackeronebugcrowdcurlburpsuitemarkdown

Tags

reportingdisclosureretestingtriageresponsible-disclosure

// checklist steps

disclosure-01

Understand disclosure timelines and programme SLAs

Read the programme policy and set expectations around response, triage, resolution, and disclosure windows before you submit.

Coordinated disclosure means agreeing a timeline with the vendor rather than going public unilaterally. Note the programme's stated SLAs for first response and triage, and record your submission timestamp so you can reference it if a deadline slips.

disclosure-02

Communicate professionally with triage teams

Write clear, reproducible reports and keep correspondence factual, patient, and free of pressure tactics.

Lead with a one-line impact summary, then give exact reproduction steps, a minimal PoC, and the affected asset. Assume the triager is overloaded and unfamiliar with your target. Avoid demanding a bounty amount or a severity rating up front; let the evidence make the case.

disclosure-03

Handle duplicates, informatives, and escalation

Respond constructively to duplicate or informative closures and use mediation only when genuinely warranted.

If a report is closed as duplicate, politely ask for confirmation that the root cause matches. For an informative or N/A closure you disagree with, add new evidence of impact rather than repeating your argument. Escalate to platform mediation only after a good-faith exchange has stalled.

disclosure-04

Verify and retest the deployed fix

Once the programme marks the issue resolved, re-run your original PoC against the patched endpoint to confirm the vulnerability is actually closed.

# Replay the exact request that originally exploited the bug
curl -si 'https://target.com/api/users/1002/profile' -H 'Authorization: Bearer <token>' | head -n 1
# A 403/404 where you previously got 200 suggests the fix holds

Do not take the resolved status at face value. Reproduce with the original payload first, and only close the loop once you have observed the patched behaviour yourself.

disclosure-05

Hunt for regressions, variants, and bypasses

After confirming the direct fix, probe for filter bypasses, alternate endpoints, and reintroductions of the same flaw elsewhere.

# Test encoding and alternate representations against the patched filter
curl -si 'https://target.com/api/users/%31%30%30%32/profile' -H 'Authorization: Bearer <token>' | head -n 1
# Check sibling and legacy endpoints for the same root cause
curl -si 'https://target.com/api/v1/users/1002/profile' -H 'Authorization: Bearer <token>' | head -n 1

Fixes are frequently incomplete, blocking one payload while missing an encoded or case-varied equivalent. A trivially bypassable patch is itself a reportable finding, so document the bypass clearly and reopen the original report where the platform allows it.

disclosure-06

Practise safe public disclosure

Only publish a write-up after the fix is confirmed and the programme has granted permission, with sensitive details redacted.

Wait for explicit disclosure permission or the policy's automatic disclosure window before publishing. Redact customer data, internal hostnames, credentials, and anything that could enable copycat attacks. When in doubt, ask the programme to review your draft before it goes live.

Overview

The report is not the finish line. How you disclose, communicate, and retest determines whether a finding becomes a paid, resolved bug or a frustrating stalemate. Coordinated disclosure keeps you in good standing with programmes and, done well, turns a single report into repeat findings through variant and regression hunting after the patch lands.

What good communication looks like

  • A one-line impact statement, precise reproduction steps, and a minimal PoC
  • Factual, patient tone that assumes an overloaded triager
  • Evidence-driven responses to duplicate or informative closures, escalating to mediation only as a last resort

High-impact follow-through

  • Bypassing an incomplete fix — encoding tricks, alternate endpoints, or case variations frequently defeat a hasty patch and count as a fresh finding.
  • Catching a regression — a previously fixed bug reintroduced in a later release.
  • Responsible public write-ups — disclosed only with permission and with sensitive data redacted, building your reputation without harming the vendor or their users.

// references

  1. https://www.hackerone.com/disclosure-guidelines
  2. https://docs.bugcrowd.com/researchers/reporting-managing-submissions/disclosure/
  3. https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html
  4. https://www.first.org/global/sigs/vulnerability-coordination/multiparty/guidelines-v1.1
  5. https://www.cisa.gov/coordinated-vulnerability-disclosure-process
← All checklists JSON ↗