In August of last year, we noted a significant problem with reporting security issues with a WordPress plugin that comes directly from WordPress, Health Check & Troubleshooting, which has 300,000+ installs. That problem being that they didn’t provide a method to report most security issues to them privately. Because of that, we reported the issues we had noticed had just been introduced in to the plugin through a public issue on the GitHub project for the plugin. It took until July for there to be a response. That response reinforced the problem. Here is the response we got:

Thank you for the report, as you note these are technically negated by various other mechanics, so this will be treated as a public hardening task.

We do ask that any potential security concerns you may notice in the future be reported via the WordPress HackerOne program, in accordance with WordPress’ responsible disclosure policies, and guidelines on reporting plugin security issues though, please, as this gives the team a chance to identify if it should be a public hardening task, or a non-public issue in a timely manner.

If you follow the link to the WordPress HackerOne program, there are a litany of restrictions on what you should report through that:

Qualifying Vulnerabilities

Any reproducible vulnerability that has a severe effect on the security or privacy of our users is likely to be in scope for the program. Common examples include XSS, CSRF, SSRF, RCE, SQLi, and privilege escalation.

We generally aren’t interested in the following problems:

• Any vulnerability with a CVSS 3 score lower than 4.0, unless it can be combined with other vulnerabilities to achieve a higher score.
• Brute force, DoS, phishing, text injection, or social engineering attacks. Wikis, Tracs, forums, etc are intended to allow users to edit them.
• Availability of XML-RPC file without PoC demonstrating a significant security impact. As noted above, this excludes DDoS and brute force attacks.
• Security vulnerabilities in WordPress plugins not specifically listed as an in-scope asset. Out of scope plugins can be reported to the Plugin Review team.
• Reports for hacked websites. The site owner can learn more about restoring their site.
• Users with administrator or editor privileges can post arbitrary JavaScript
• Self-XSS issues within wp-admin requiring users with unfiltered_html capability are not under the scope of this program. For example, script execution within /wp-admin as an administrator or editor on a single-site installation. Only the cases where a less-privileged user is able to execute XSS attacks on a higher-privileged user will be under the bug bounty scope.
• Disclosure of user IDs
• Open API endpoints serving public data (Including usernames and user IDs)
• Path disclosures for errors, warnings, or notices
• WordPress version number disclosure
• Mixed content warnings for passive assets like images and videos
• Lack of HTTP security headers (CSP, X-XSS, etc.)
• Output from automated scans – please manually verify issues and include a valid proof of concept.
• Any non-severe vulnerability on irclogs.wordpress.org, lists.wordpress.org, or any other low impact site.
• Clickjacking with minimal security implications
• Vulnerabilities in Composer/NPM devDependencies, unless there’s a practical way to exploit it remotely.
• Theoretical vulnerabilities where you can’t demonstrate a significant security impact with a PoC.

The security issues we were reporting to them run afoul of the first bullet point, “Any vulnerability with a CVSS 3 score lower than 4.0, unless it can be combined with other vulnerabilities to achieve a higher score.”, and the last bullet point, “Theoretical vulnerabilities where you can’t demonstrate a significant security impact with a PoC.”

We replied, pointing out that problem with the discrepancy between what WordPress recommends doing and the reporting system, but there has been no response so far.

This isn’t just an issue with this plugin, as the bug bounty program is also more broadly pointed to for the whole WordPress project.

In general, bug bounty programs are not an acceptable alternative to having a proper process to report security issues. That is because of limits on what can be reported, as well as other issues. Another one being legal requirements of those programs that may conflict with security providers’ legal or ethical obligations that they have to their customers.

Our Plugin Security Scorecard Warns About Such Situations

Our new Plugin Security Scorecard provides a warning when we know that the developer of a plugin is directing reporting security issues to a bug bounty program where many of them are not accepted. Hopefully that will lead to developers changing practices to address this problem.