Retesting lets you ask researchers to verify that a previously reported vulnerability is still reproducible after deploying a fix so you can close submissions with confidence.
⚙️Roles: Company Admin, Program Admin, Program Editor, Program member, Group member (only when the group is linked to the submission)
Requesting a retest
Go to Submissions
Open any submission that is in status Accepted and for which you have deployed a fix.
Click Request retest.
Enter a retest bounty. The minimum retest bounty is 50 EUR, USD, or GBP.
Set a retest deadline between 5 and 30 days.
Send the request. The submitter receives an invitation to perform the retest.
The researcher has until the deadline to accept or reject the request. If no action is taken by then, it will automatically expire allowing you to move the submission out of status accepted.
After requesting a retest
The researcher can Accept or Reject the request. If they do not respond before the deadline, the request expires and you can close the submission.
If the request is accepted, the researcher will attempt to reproduce the vulnerability.
Once the retest is submitted, you receive the results along with supporting proof.
Review the results and, if the fix is confirmed, click Accept retest to award the bounty and mark the issue as resolved. If the vulnerability still exists, you can apply additional fixes and optionally request another retest.
💡Note: You can cancel a retest request as long as the researcher has not accepted it yet. This is useful if you no longer need verification and want to close the submission.
Best practices
Request retests only after you have deployed and validated your fix internally to avoid unnecessary cycles.
Set a realistic retest bounty that matches the effort required to reproduce the issue. Increase the default amount when the retest involves complex environments or test setups.
Communicate clearly when fixes affect access, test accounts, or configuration so the researcher can perform the retest efficiently.