When it comes to security issues with WordPress plugins, the team running the WordPress Plugin Directory continues to make matters worse. One area we have seen that occurring for some time (and that we have been criticized for taking action to protect our customers from) is with the closure of popular plugins with security issues. That occurred again recently with Brizy, which has 60,000+ installs. The WPScan Vulnerability Database belated warned about a vulnerability in the plugin yesterday with this timeline (we had warned any of the customers of our service that were impacted last month):

February 10th, 2020 – Report received & WP Plugins Team notified.
February 12th, 2020 – WP Plugin Team Investigating
February 12th, 2020 – v1.0.114 released in SVN, fixing the issue. However, the plugin is still closed
March 3rd, 2020 – Seeing probes checking for the issue
March 4th, 2020 – Contacted WP Plugin to have an ETA about re-opening the plugin
March 5th, 2020 – Plugin can not be re-opened yet as there are other issues (including legal ones), as well as incomplete fixes
March 5th, 2020 – Issue disclosed, we recommend to remove the plugin until a new version is available and downloadable

There are a couple of notable issues with that.

First, the issue was not actually fully resolved in version 1.0.114 (that was one of two plugins the WPScan Vulnerability Database yesterday claimed were fixed, despite incomplete fixes), though it was fixed enough that the way that non-targeted hacks would try to exploit it would fail.

Second, the probing for the plugin began much sooner, publicly available data showed that occurring as of February 14:

Fishing for exploitable WP stuff /wp-content/plugins/brizy/public/static/css/style.css

Yesterday, subsequent to WPScan’s public mention of this, the plugin was re-opened on the Plugin Directory despite no additional changes being made to the plugin, so the plugin is still known to be vulnerable.

The re-opening now is baffling, since there would be good reason not to re-open it (but to take other actions, we will get to in a moment) and they were apparently claiming they couldn’t re-open it due to that very reason on the same day. But if they were going to do that, it would make sense to do that right after the vulnerability was fixed enough to prevent widespread exploitation instead of weeks after hackers started targeting the plugin.

Unfortunately the team running the Plugin Directory is permitted to operate without oversight and while leaving the public in the dark, so there isn’t an existing mechanism for accountability here or any reason to believe they will even consider changes to avoid situations like this in the future.

We had contacted the news outlet WordPress Tavern, which is owned by the person ultimately in control of WordPress, Matt Mullenweg, on Monday suggesting the situation could be in use of some coverage, but haven’t heard anything back.

Since this isn’t a new issue, there are multiple improvements that we have already suggested that could have made this situation better:

Not having fixes made publicly available before being reviewed, since it can make it easier for hackers to find and exploit vulnerabilities that led to closures of popular plugins. In this case it made it extremely easy to figure out what was at issue.

As far as we are aware the team running the Plugin Directory have a capability to allow those using a plugin to update without allowing new installs or downloads, which would be a good option to use in a situation like this, but it hasn’t been used here or in similar situations. They also have the capability to force websites to update to the new version, though usage of that is probably controversial, based on the discussion of a similar capability with major WordPress updates.

The team also has the capability to fix things themselves and we have repeatedly offered to help them with fixes in the type of situation where a vulnerability is likely or already being exploited, so this could have been properly fixed the same day it was closed if the developer wasn’t able to do that.

WordPress warning about plugins the team knows are vulnerable would also be a good idea, though in situation like this that would probably be best used in conjunction with providing an updated version and maybe with the warning delayed until after people have had a chance to update to fix the more serious issue.