Recently we have been having an issue where someone (or someones) that has the ability to edit and delete post on WordPress’ support forum had been doing those things to some of our posts on their support forum. Last week discussed on such instance where that look liked an attempt to cover up the fact that WordPress has an ongoing problem where plugins they know contain a vulnerability that have been removed from the Plugin Directory due to that, then return to it without the vulnerability being fixed. Over at our main blog we discussed that it appears that whomever is doing it doesn’t want the public to know what is going, as in another instance they also deleted a reply to a post of ours that just thankedus for the information we provided, which if it remained, would have made it obvious that a post from us had existed and had been deleted. While preparing to write this post about the issue of WordPress’ handling a vulnerability in a plugin that appears to have been abandoned, we noticed that another such instance of a deletion that looks like an attempt to cover up yet another piece of WordPress’ current poor handling of vulnerabilities in plugins.

On July 17 we saw requests for a .css file from the plugin Form Lightbox across our websites. That is usually an indication that a hacker is probing for usage of the plugin before trying to exploit a vulnerability in it. Seeing as the requests hit all of our websites, that pointed to there probably being a large campaign to exploit something in the plugin. After noticing the request we started trying to figure out if there was a vulnerability so that we could add it to our data and see what we could do about getting it fixed. We quickly found an option update vulnerability in the plugin, which would allow anyone to change WordPress’ options (settings). One possible way that could be exploited is to turn on user registration and set it so that new users had the Administrator role, giving the attacker the ability to do almost anything on the website. Later in the day the plugin was removed from the Plugin Directory, so at least one other person had noticed the issue and notified the Plugin Directory before we had done so.

On July 20 a post was started on the support forum for WordPress, Plugin disappears from repo as vulnerability is revealed?. The original post was later edited, but from a cached copy here is how it read (the bolded portions were later removed by someone else with the ability to do that):

Hi,
Is there any rules about triaging security vulnerabilities in plugins?

I was a fan of Form Lightbox {DEAD LINK}, a simple plugin that let you embed a form in a lightbox.

According to Google’s cache, it was still available on 16/7, 2 days before this was published:

https:// www.pluginvulnerabilities.com/2016/07/18/option-update-vulnerability-in-form-lightbox/

There’s a giant security hole in the plugin. I’ve had 4 sites exploited using it. A simple google search reveals a number of others that have been bitten.

If WordPress.org pull the plugin (in line with the disclosure practices of pluginvulnerabilities.com) , and the author fails to patch it, and make it available again, can someone else step up, take it over and issue a patch?

Otherwise, those affected are left high and dry (until they find out how their sites are being pwned, by other means).

The “WordPress.org Tech Dude” responded:

If WordPress.org pull the plugin, and the author fails to patch it, and make it available again, can someone else step up, take it over and issue a patch?

If we pull the plugin for security reasons, then the author usually patches it. If it’s severe enough, we may patch it ourselves after an author does not respond. This is handled on a case by case basis.

After noticing the thread through our monitoring of the support forum for vulnerability related issues, we saw that there were a number of problems with that reply, which we address in a reply that was deleted some time later:

Seeing as we are the people that are reporting many of the vulnerabilities to the Plugin Directory that cause plugins to be pulled, we can say that the reality is that plenty of those plugins never get fixed. In other cases they are not fixed in a timely manner. Also, in some cases you guys put the plugin back in the Plugin Directory even though the vulnerabilities have not actually been fixed, including a recent case where it looks like a hacker had been exploiting a plugin prior to it being removed from the Plugin Directory.

In the case of the plugin mentioned here, a security issue doesn’t get much more severe than this. Not only does the plugin have an easily exploitable vulnerability, but it appears that a hacker is already exploiting it. That is how we became aware of the issue in the first place.

As mentioned in the post cited above, the plugin was removed before our post was released, so the post’s release had nothing to do with the plugin being removed.

If you used our Plugin Vulnerabilities plugin you would have been warned about this vulnerability a couple of days ago, since we include data on vulnerabilities in plugins that have hacking attempts against them in the free data included with that plugin.

There was never any reply to our reply, so it seems that no one from the WordPress side wanted to dispute anything we had said in it. They then could have taken it as wake up call that things need to be improved (something we would happy to help them with). Instead at some point later our post was completed deleted without any notification to us that it in some way violated any policy on the forum. What has happened with the plugin since then, shows that, not surprisingly, trying to cover up things in this way doesn’t actually deal with the issue.

If you go to the plugin’s page on the Plugin Directory now you will see that it is still removed (the message mentioning that it has been removed in the screenshot was added to the page by the Plugin Vulnerabilities Chrome extension):

That doesn’t always mean that nothing has been done, as from what we have seen from checking on what is happening with other plugins with vulnerabilities is that there can sometimes be a significant delay between the developer submitting a new version to the underlying the Subversion repository and the plugin returning to the Plugin Directory (probably due to some review of the fix needing to occur first). In this case though, the most recent change to the plugin remains one from three years ago:

As we mentioned in our reply in that post, “In the case of the plugin mentioned here, a security issue doesn’t get much more severe than this.”, so if WordPress is going to patch severe vulnerabilities when the plugin’s author this seem to be one where that should have happened. That means that for the 10,000+ websites using the plugin (according to wordpress.org, as of the time the vulnerability started being exploited) are left without a secured version to update to. We don’t think that WordPress necessarily should be expected to fix any vulnerabilities in plugins, but what they should at least do is notify those using plugins that they are vulnerable. That is something that they could have done long ago, but they continue to refuse to do it on the basis that it would put websites at risk, which doesn’t make much sense in case like this, where a hacker is already exploiting the vulnerability on a large scale and others are able to easily identify an exploitable vulnerability in the plugin.