Feedback on Duplicate Report Merging and Fair Bounty Consideration for High-Effort Findings in Elastic Bug Bounty Program

Meta Elastic
1

Hi Elastic team,

I wanted to share some feedback regarding how duplicate reports are handled in the bug bounty program.

In my submission, there were more than 55 duplicate reports that were eventually merged into a single report. I completely understand why duplicates need to be consolidated, especially to keep things organized and avoid repetition. However, I’d like to provide some additional context around the effort and work behind these findings.

I spent a significant amount of time researching and testing various endpoints using different methods and approaches. This wasn’t a quick or simple process — it involved going through multiple layers of the system, trying different scenarios, and carefully validating each behavior I observed.

During this research, I discovered several different issues and potential attack paths within Elastic Stack environments. In some cases, depending on configuration and exposure, these issues could potentially lead to serious impact such as service disruption or making deployments temporarily unavailable or inaccessible to users.

A lot of this work was done over an extended period of time, including late-night sessions where I continuously tested, refined, and verified each finding to ensure it was accurate and reproducible before submitting.

From my side, even though the reports were merged due to duplication, the effort behind identifying these issues was quite large and required deep investigation across multiple angles. Because of that, I just hope the overall scope, time investment, and depth of research can still be taken into account when evaluating severity and bounty decisions.

I fully understand and respect the duplicate handling policy, but I also wanted to highlight that in cases like this, a single merged report may represent a much larger body of work and multiple meaningful findings.

Thank you for taking the time to read this and for running the bug bounty program. I appreciate the work the Elastic team is doing.

2

Additionally, these 55+ reports actually span different attack paths, including various endpoints, features, and input points, all of which are reproducible in Elastic Stack cloud deployments. Identifying all of these vulnerable points required a significant amount of time and deep exploration across multiple areas of the system.

On top of that, this report is now more than 5 months old, and I have not yet received any bounty for it.

Considering that these findings cover multiple distinct attack paths, including unauthenticated access scenarios, as well as cases where requests can bypass limits such as 413/414 under low-privileged roles with certain configurations, the overall impact in many cases results in 502 errors that make the service unavailable and affect all users of the Elastic Stack deployment. Because of this, I hope there can be a reconsideration of both the severity level and the bounty amount.

My expectation is that the complexity and the number of vulnerable points identified are better reflected in the final evaluation, as each path may differ in technique but still leads to a significant availability impact.

3

Thanks for reaching out! After talking to my colleagues, they will continue the discussion on the bug bounty platform.