Hacker publicly discloses details of a report that was previously submitted to a team. However:

• the team/platform has rejected the report as invalid
  OR
• the bug has already been confirmed to be fixed

Resolution: A platform ban seems excessive in these situations. A warning or a temporary program ban should me more than enough, given the very low risk of the disclosure being dangerous.

Standardizing a trivial punishment or no punishment for these situations would incentivize more accurate triage, and would probably remove a lot of friction from the process of publishing research.

Hacker submits a bug to a program that has an open scope brief. The bug is on an acquisition. The program owner does not control the IT infrastructure or staff of the acquisition.

Resolution: The program owner should make a good faith effort, verified by the platform, to inform the acquisition. Should the acquisition benefit from the submission, the program owner should pay the bounty. The brief should be updated to reflect if acquisition(s) are in scope.

Situation:
From time to time, triage will close XSS reports as dupes based on input rather than output (so when eg a name input is echoed in entirely different pages/functionalities, they will close reports as dupes of each other). When appealing, it's sometimes resolved by the platform, sometimes passed onto the program to decide, and sometimes reports are left closed.

Resolution:
The platform should correctly triage reports (ideally directly, otherwise on appeal) & dupe XSS on output.

Reasoning:
XSS is an output vulnerability, and that's where the issue needs to be resolved. That's also how it's mostly - but not always - handled. Adding a generic input filter or WAF over the input will not properly fix the issue. Among other, already placed payloads will continue to trigger, allowing continued exploitation.

Situation: Retests are currently not handled uniformly. Some programs offer a reward for retests, some don't. Some offer a reward for a bypass, some don't.

Resolution:
Programs should have the option to pay a flat amount for a retest. This should be optional and left to the program. No demand for a retest should take place without payment. If a bypass for the fix can be found (whether a retest was requested or not), a new report should be opened and rewarded.

Reasoning & Discussion:
Not sure how to handle it when the issue can be reproduced as-is (ie a retest was requested and/or the report was marked as resolved, but the issue still exists in its original form). For a bypass, there's a new vulnerability which warrants a new report. But when the program is mistaken about having released a fix, it's not clear what to do. If a retest was requested, I think the retest payment is enough. Otherwise, I'm not sure if a new report is warranted.

Hacker submits a bug but closed as duplicate. But after the old report closed as resolved, duplicated report still reproducible.

Resolution: Disclosed report status should changed to triage and, the program should pay the relevant bounty.

Hi,

Since it covers only the platform related programs, can we expand it to non platforms VDPs too? Or I can create a separate repository for it.

Issue: Report is open/triaged for more than 12 months. There is no update from the program for several reasons:

• an asset which report was referring to does not exists anymore (was decommissioned by the program, rebuild with different tech stack and vulnerability is no longer present/not reproducible etc.)
• program is no longer active or was closed before the report was resolved

Despite several requests for update from Hacker, there is no clear response from either a program or platform's triage team.

Prerequisites

• vulnerability was valid at the moment it was reported, and report itself follows all requirements of valid report
• there was no bounty awarded
• report is open/triaged for more than 12 months and there are at least 180 days since the latest activity in the report (update form the platform/program etc.)

Proposed resolution: Platform should respond in <90 days with proposed ways of resolution. Report should be closed either as Informative if there is no clear way to determine the real impact/validity of reported vulnerability (no PoC, screenshots etc.) or as Resolved, if there is a clear evidence that the vulnerability in fact was found and reported in the expected way (report contains screenshots, PoC, video, detailed reproduction steps etc.) and the severity is at least Low

I believe the details about the final state of the report depends on the platform, but in general report should be handled in favor of the Hacker (so it should counts as a valid report, allows to gain reputation or other points awarded by the platform etc.).

Other things to consider:

• if program was paying bounties for valid, resolved reports - what is expected from the platform to be done in such case
• should disclosure be allowed - if yes, who makes the final decision (Platform or Hacker, as platform is no longer a part here)

Exclusion

• report is open for more than 12 months, but program responds in a timely manner that is working on resolution and gives updates in response to Hacker's comments/requests for update

Rationale
I can confirm scenarios described in this issue exists. I have several reports stuck in such situation, some of them are open and triaged for around 4 years now.
Example: I was asked to verify fixes, applied to asset which is no longer even available online. When I commented on this, there was (and still there is not) any response from the platform's triage team member(s) for 9 months now. Report was triaged 3 years ago in a program where, according to statistics, 96% of reports "Meet response standards" defined by platform and average time to resolution is 6 months.

Hacker submits a vulnerability with a CVSS score that sits within a programs specified reward range. The program rewards the report at the bottom of the specified range.

Resolution:
If a bounty range is published by a program, it should be made clear what reward a CVSS score would receive.

For example:
High Severity: Range $1000 - $3000
Vulnerability Score: 8.0
Reward: $2000

For any programs using CVSS, an approximate reward value for a submission should be automatically calculated and made visible to both reporter and program.

A hacker submits a report for a vulnerability that was previously reported and fixed and has become vulnerable again due to a reversion. The program closes as dupe due to previous report.

Resolution:
The program should pay the full reward amount.

Hacker exploits a vulnerability on site1.com through an endpoint on site2.com. The triager attributes the exploit to site2.com which has a lower reward amount.

Resolution:
A triager and program should make a good faith effort to attribute a vulnerability to the highest paying impacted resource.