As programs receive vulnerability reports and work on deploying fixes, they need proof that their vulnerabilities have actually been fixed. Retesting is a good way to secure your asset’s data by asking hackers to verify whether a fix has been made. With retesting, you can elect to have hackers retest your vulnerabilities to verify the fixes. Hackers focus solely on the original issue during a retest; bypasses are treated as new reports.
Note: For response programs (VDPs) using HackerOne's triage services, the triage team will retest the vulnerabilities to verify the fixes instead of hackers when a retest is requested.
How it Works
To have hackers retest a vulnerability:
Choose the report in your inbox that you want to assign a hacker to retest.
Change the action picker to Request retest.
Choose the award amount for the retest.
We'll suggest a reward amount between $50 and $500 whenever possible. You can customize the reward for retesting, with a minimum starting at $50.
The reporter will be invited to perform the retest for the specified amount when you request the retest.
Click Request retest.
The original hacker who submitted the vulnerability will be invited to take part in the retest.
The hacker will submit their findings in the Retest findings form at the bottom of the report. The form consists of these fields:
Are you able to reproduce the vulnerability report?
Please provide us with a short summary of how you retested the vulnerability and upload any attachments of your validations.
After the hacker submits their findings, you’ll be prompted to either Approve and resolve or Reject the retest. When approving the retest, the award amount can be increased if desired.
If you choose the following actions for the retest:
Action | Scenario | Details |
Approve and resolve | The hacker says the vulnerability is fixed. | The report will close and will be marked as Resolved. The hacker will also be awarded a bounty. |
Reject | The hacker says the vulnerability is fixed. | If you think the retest wasn't done, you can reject it. Only do this if you're sure it wasn't completed. Please give the hacker a summary explaining why. To request another retest, go back to step 1. |
Approve | The hacker says the vulnerability is not fixed. | The report will move back to Triaged and stay open for the team to implement a fix. The hacker will be awarded a bounty. |
Reject | The hacker says the vulnerability is not fixed. | You need to provide a summary to the hacker explaining why you’ve rejected the retest. A rejection should primarily be reserved for instances where the hacker did not perform the retest, or if there was a failure to follow specific retest guidelines. You can request another retest for the report by returning to step 1.
The status of the report will be changed to its previous state. |
If the original hacker rejects the retest, the report will pass back to you in its previous state. You can also cancel a retest if the original hacker does not respond in time.
Note: Retesting is not available for anonymous reports.
When requesting a retest, remember that each retest comes with its own award, and you’ll need to pay for each one, even if the issue remains unresolved. Approving a retest confirms the researcher has checked it, while rejecting means they haven't. If the bug persists, you can request another retest after your developers have fixed it.
Payments
Hackers will be awarded a bounty for each successful retest. Awards for retests will be paid from your bounty pool. If you're using the consumption tier to pay for your bounties, payments for retests will count toward the tier.