Originally, bug bounty programs were helpful to improve security for a couple of reasons that had nothing to do with payouts for vulnerabilities. They provided a clear method to report security issues to developers and they signified that developers were going to address the issues instead of doing something like threatening a lawsuit. Then the security industry saw yet another way to make money, while making security worse. Security providers, including HackerOne, came along telling companies that they needed a bug bounty program and they should pay them to manage it. That led to an unnecessary third-party being involved in the process and having companies that were not interested in fixing issues seeming as if they did. The results haven’t been good.

One of the problems with this process, as we previously noted with the programs from WordPress and Automattic, which are handled by HackerOne, is that they create a situation where there isn’t a method to report many security issues. This is something we have tried to address with WordPress, with no success.

Along those lines, recently someone tried to report a vulnerability to the ticketing system company Zendesk earlier this year. They handle that through HackerOne, which provided this response to the report:

Thank you for your submission! Unfortunately, this particular issue you reported is explicitly out of scope as outlined in the Policy Page:

SPF, DKIM, DMARC issues.

Your effort is nonetheless appreciated and we wish that you’ll continue to research and submit any future security issues you find.

The reporter try to get this passed directly to Zen Desk and got this response:

Thank you for your report and follow-up discussion regarding the support ticket email spoofing vulnerability. As a HackerOne mediator, I’ve reviewed the report details, activities, and Zendesk’s bug bounty policy thoroughly.

While we acknowledge that the ability to gain unauthorized access to support tickets is a serious matter, Zendesk’s policy explicitly lists “SPF, DKIM, DMARC issues” under the Bounty Ineligible Issues section. Since the root cause of this vulnerability involves email spoofing by bypassing those email authentication protocols, it falls squarely into the excluded issues per the policy.

I understand your perspective that the potential impact makes this a high-risk vulnerability regardless of the prerequisites. However, bug bounty programs have to draw clear lines around scope to manage expectations and workload.

Therefore, after consultations with the team, we have decided that this report will remain marked as “informative” and out of scope for their bug bounty program.

We encourage you to continue researching and reporting any other vulnerabilities you discover that fall within the program scope outlined in Zendesk’s policy. Your contributions are valued by the HackerOne community.

Please let me know if you have any other questions!

The part that stands out there is the statement that “bug bounty programs have to draw clear lines around scope to manage expectations and workload.” The HackerOne employee’s job isn’t to make software secure, it is to limit how much HackerOne spends managing the bug bounty program.

That person’s post then goes on to detail how they used the issue that wasn’t being addressed to get bounties from companyies using Zendesk. They also mentioned that “[a]t least one or two companies reportedly cut ties with Zendesk after my disclosure, canceling their agreements altogether.” Once that happened, Zendesk got in touch with the reporter and had this incredible response:

We kindly request you to keep this report between you and Zendesk. We received tickets from customers regarding this issue mentioning you and it has caused unnecessary communications on our end.

They state that you were able to use this vulnerability to gain access to their Slack instance but you have not provided that detail to us. Could you share your ticket-trick POC demonstrating this?

Zendesk hadn’t kept the report between the two of them, as the reporter hadn’t even been able to reach out to them directly.

Zendesk didn’t take this as a chance to bring their bug bounty program in house. Instead, they put out incredibly dishonest statement. It starts “This summer, Zendesk identified a vulnerability through our bug bounty program, which we worked with a researcher to address.” They didn’t discover anything, someone attempted to report it to them. They ended it by saying this:

We also want to address the Bug Bounty program associated with this case. Although the researcher did initially submit the vulnerability through our established process, they violated key ethical principles by directly contacting third parties about their report prior to remediation. This was in violation of bug bounty terms of service, which are industry standard and intended to protect the white hat community while also supporting responsible disclosure. This breach of trust resulted in the forfeiture of their reward, as we maintain strict standards for responsible disclosure.

The response that the reporter got was that their report was out of scope for the bug bounty program, so how could they have violated the terms of service for something that was relevant to the bug bounty program?

Getting back to WordPress, we have found that plugin developers who use third-party bug bounty programs have general problems with handling security. That shouldn’t be surprising since if they cared about security, they wouldn’t be using one of those.