Verify the fix yourself first, then ask the reporter to retest with a clear note: what changed, where to test, how long they have, and that declining is fine. Retesting is a courtesy from the researcher, not an obligation, so make it easy to say yes.
Why retest
Fixes fail in boring ways: one endpoint patched and a twin missed, a filter that blocks only the exact payload, a change that works in staging but not in the release build. The original reporter already knows the trick, so they often catch these quickly. OWASP's guidance says that although researchers have no obligation to retest, feedback on a fix is very beneficial, and that organizations may ask for help retesting. CISA's directive likewise suggests that where contact details are known, you consider asking the reporter to evaluate the remediation's effectiveness.
Steps
- Rerun your own reproduction log against the fixed build. If the original steps still work, stop and fix again.
- Try variations. Change the payload, the encoding, the HTTP method and the account role.
- Check sibling code paths for the same weakness.
- Prepare a test target. A fixed release in a test environment or an invitation to test the production fix, within scope.
- Send the request (template below).
- Set a window, such as seven days, and say what happens after it.
- Record the result in the case record.
A message template
Keep it short and human:
Hello, we have a fix for the issue you reported. It is in version X, and in this test environment. Would you be willing to try your original steps and any variations? We would like your feedback by a date. If you are unable to, no problem, and we will go ahead with the release on the date we shared before. Thank you again for the report.
What to do with the answer
| Reply | Next step |
|---|---|
| Fixed | Confirm advisory timing and credit |
| Still works | Thank them, reopen the case, update the timeline |
| Partially fixed | Ask for the exact residual path, fix, retest again |
| No reply | Release anyway at the agreed date, and note that retest was offered |
Keep the release date honest
Do not hold a release forever waiting for a retest. OWASP's view on timelines is that regular updates matter more than a perfect date. Tell the researcher when you plan to publish and why. If you need more time, say it before the date arrives. See telling a researcher your fix will slip.
Credit
A retest is extra work. Acknowledge it in your advisory and thank the person privately too. Our post on thanking and crediting researchers covers the options.
Add a regression test
After a successful retest, add an automated test for the exact pattern so it cannot return. Safeguard's autonomous remediation can open fix pull requests for dependency issues (off by default, with every category set to manual approval), and a regression test keeps those fixes honest too.
Quick check
What if the researcher wants a bounty for the retest?
Retesting is part of the original report unless your program says otherwise. If you want paid retests, state that in your policy ahead of time.
Should I retest internally first?
Yes. Sending a researcher a broken fix wastes their time and yours.
Sources
- OWASP Vulnerability Disclosure Cheat Sheet
- CISA BOD 20-01: Develop and Publish a Vulnerability Disclosure Policy
Last reviewed: 19 October 2026.
