Retesting Fixed Bugs: Etiquette That Keeps You Welcome
You got the "Resolved — please retest" ping. This is where good hunters stay welcome and noisy ones get rate-limited.
Retest is a verification job, not a second full audit on the company's dime without permission.
Stay inside the original boundary
Reproduce the exact path you reported. Confirm the old PoC fails. Then probe the obvious bypasses adjacent to that fix: same parameter with encoding, a sibling endpoint, the mobile API twin, an alternate content type. That is fair residual testing.
What is not fair: using the open ticket as a blank check to fuzz unrelated admin panels for three days. File new issues separately so severity and bounty math stay honest.
Coordinate timing. If engineering says the patch lands after 18:00 UTC, do not blast the endpoint at 17:55 with a hundred parallel workers "just to be sure." Patches sometimes roll out per region; say which edge or locale you hit.
If the program asks you to wait for a specific build number or feature flag, wait. Retesting yesterday's binary wastes everyone's night.
Prove fixed — or prove not fixed — with fresh evidence
Use a new canary. Old screenshots convince nobody that you retested today. Show:
- Pre-fix behavior (or cite the original attachment if still valid)
- Post-fix attempt with the same steps failing closed
- Any bypass that still works, in a short addendum with its own steps
If the fix is partial — blocked in UI, alive in API — say exactly that. Partial fixes are common. Clarity gets you either a reopen or a correct severity on the leftover path.
Do not claim "still vulnerable" because a WAF blocked you once and a retry went through. Capture both responses and describe consistency. Flaky edge rules need careful wording so engineering does not chase ghosts.
Know when to stop arguing
Sometimes the program accepts residual risk: feature removed, privilege model changed, dangerous endpoint deleted. If your original impact is gone, close the loop. You can still file a new report for a weaker leftover if it meets the bar on its own.
Do not demand a bounty renegotiation in the retest thread unless policy invites it. Severity disputes belong in a calm comment with CVSS notes and demonstrated impact, not in a retest NACK spam.
Leave the door open
A short "Fix holds on my side; thanks" helps their metrics and your reputation. Programs invite researchers back who close cleanly and do not turn every patch into theater.
If the program offers a hall-of-fame or private Slack for trusted researchers, retest etiquette is how you stay invited. Being "technically right" while thrashing a fragile endpoint overnight is still a lose.
Document the build or commit you tested against when the program publishes one. "Works on my cache" is not a retest. State region and UTC time too.
Retesting is part of the craft. Treat production like someone else's pager depends on it — because it does.