A security service called Plugin Vulnerabilities, founded by John Grillot, is taking a vigilante approach to addressing grievances against WordPress.org support forum moderators. The company is protesting the moderators’ actions by publishing zero-day vulnerabilities (those for which no patch has been issued) and then attempting to contact the plugin author via the WordPress.org support forums:

Due to the moderators of the WordPress Support Forum’s continued inappropriate behavior we are full disclosing vulnerabilities in protest until WordPress gets that situation cleaned up, so we are releasing this post and then only trying to notify the developer through the WordPress Support Forum. You can notify the developer of this issue on the forum as well. Hopefully the moderators will finally see the light and clean up their act soon, so these full disclosures will no longer be needed (we hope they end soon).

In the linked incidents cited above, Grillot claims that moderators have deleted his comments, covered up security issues instead of trying to fix them, and promoted certain security companies for fixing hacked sites, among other complaints.

In response, Plugin Vulnerabilities has published a string of vulnerabilities with full disclosure since initiating the protest in September 2018. These posts detail the exact location of the vulnerabilities in the code, along with a proof of concept. The posts are followed up with an attempt to notify the developer through the WordPress.org support forum.

Grillot said he hopes to return to Plugin Vulnerabilities’ previous policy of responsible disclosure but will not end the protest until WordPress.org support forum moderators comply with the list of what he outlined as “appropriate behavior.”

WordPress’ security leadership is currently going through a transitional period after Aaron Campbell, head of WordPress Ecosystem at GoDaddy, stepped down from his position as head of security in December 2018. Automattic Technical Account Engineer Jake Spurlock is coordinating releases while the next person to wrangle the team is selected. This announcement was made in the #security channel, but Josepha Haden said there are plans for a more public post soon. Campbell did wish to publish the details of why he stepped down but said that he thinks it is important to rotate that role and that “the added influx of fresh energy in that position is really healthy.”

When asked about the Plugin Vulnerabilities’ protest against WordPress.org, Spurlock referenced the Responsible Disclosure guidelines on WordPress’ Hackerone profile. It includes the following recommendation regarding publishing vulnerabilities:

Give us a reasonable time to correct the issue before making any information public. We care deeply about security, but as an open-source project, our team is mostly comprised of volunteers.

Spurlock said that since those guidelines are more pertinent to core, dealing with third-party plugins is a trickier scenario. Ideally, the plugin author would be notified first, so they can work with the plugins team to push updates and remove old versions that may contain those vulnerabilities.

“The WordPress open-source project is always looking for responsible disclosure of security vulnerabilities,” Spurlock said. “We have a process for disclosing for plugins and for core. Neither of theses processes include posting 0-day exploits.”

Grillot did not respond to our request for comment, but the company’s recent blog posts contend that following responsible disclosure in the past would sometimes lead to vulnerabilities being “covered up,” and even at times cause them to go unfixed.

WordPress.org support forum moderators do not permit people to report vulnerabilities on the support forums or to engage in discussion regarding vulnerabilities that remain unfixed. The preferred avenue for reporting is to email plugins@wordpress.org so the plugins team can work with authors to patch plugins in a timely way.

However, in the wild west world of plugins, which includes more than 55,000 hosted on WordPress.org, there are times when responsible disclosure falls apart and occasionally fails users. Responsible disclosure is not a perfect policy, but overall it tends to work better than the alternative. The Plugin Vulnerabilities service even states that they intend to return to responsible disclosure after the protest, essentially recognizing that this policy is the best way to coexist with others in the plugin ecosystem.

In the meantime, publishing zero-day vulnerabilities exposes sites to potential attacks if the plugin author is not immediately available to write a patch. The only thing WordPress.org can do is remove the plugin temporarily until a fix can be released. This measure protects new users from downloading vulnerable software but does nothing for users who already have the plugin active. If site owners are going to protect themselves by disabling it until there is a fix, they need to know that the plugin is vulnerable.

Plugin Vulnerabilities’ controversial protest, which some might even call unethical, may not be the most inspired catalyst for improving WordPress.org’s approach to security. It is a symptom of a larger issue. WordPress needs strong, visible security leadership and a team with dedicated resources for improving the plugin ecosystem. Plugin authors need a better notification system for advising users of important security updates inside the WordPress admin. Most users are not subscribed to industry blogs and security services – they depend on WordPress to let them know when an update is important. Refining the infrastructure available to plugin developers and creating a more streamlined security flow is critical for repairing the plugin ecosystem’s reputation.