Coordinated Disclosure & Retesting
Navigate coordinated disclosure timelines, communicate professionally with triage teams, handle duplicates and escalation, and rigorously retest fixes for bypasses and regressions.
Tools
Machine-readable JSON available at:
https://reconatlas.pages.dev/api/checklists/disclosure-retestTags
// 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
- https://www.hackerone.com/disclosure-guidelines
- https://docs.bugcrowd.com/researchers/reporting-managing-submissions/disclosure/
- https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html
- https://www.first.org/global/sigs/vulnerability-coordination/multiparty/guidelines-v1.1
- https://www.cisa.gov/coordinated-vulnerability-disclosure-process