One of the key pieces of advice for keeping your WordPress website secure is to keep your plugins up to date, since that prevents the possibility of the website from being exploited through a security vulnerability that has been fixed in a newer version of the plugin. There is a limitation to that though, that it only protects you from vulnerabilities that the developer has fixed. So what happens if a vulnerability is discovered in a plugin available in the Plugin Directory and it doesn’t get fixed by the developer? Once the Plugin Directory is notified of the vulnerability the plugin is removed pending a fix, unless the vulnerability is really minor. That protects anyone who is not yet using the plugin, since they won’t be able to install it through normal means, but what about those who already have it installed? For them nothing happens. That is something that has concerned us for years.

As part of our effort to improve the situation, four years ago we put a suggestion up on the Ideas section of the wordpress.org website suggesting that webmasters should be alerted when they are using a plugin that has been removed from the Plugin Directory. Not to long after that idea was marked as “Good idea! We’re working on it”.

Around the same the “Lead Plugin Wrangler” at WordPress explained that a solution was being worked on:

FWIW, we’re working on a solution. Part of the problem is we’ll close a plugin for many reasons:

* Guideline violations
* By request
* Security
* Licensing

And then of course there are subsets to these, like would you care about an alert if I told you a plugin was closed because it has affiliate links on the repository page? It doesn’t impact the user as much as all that. So we have to sort out how best to alert the right times, and then we have to figure out the best way to alert without spreading FUD.

We’ve actually started a step one on the backend, to allow the admins who moderate a better way of seeing what’s closed and what isn’t. Next up, a way for us to tag WHY a plugin was closed. It’s being worked on though 🙂

Four years later that still hasn’t happened. Two months ago the same person explained why it hasn’t happened:

We cannot provide this service at this time.

IF an exploit exists and we publicize that fact without a patch, we put you MORE at risk.

If an exploit exists, hackers will be targeting the vulnerability en-mass.

That’s exactly the issue. If we make it known there is an exploit, the hackers attack everyone :/

If we don’t tell anyone, then hackers who DO know will attack, but they would have anyway.

We will get in to why this is position is misguided at best in a second, but first it is worth mentioning that this isn’t a new stance. Back in February of 2012, our plugin No Longer in Directory, which lists installed plugins that have been removed from the Plugin Directory, was first rejected for inclusion in the Plugin Directory due to plugin’s description emphasizing that plugins can be removed the Plugin Directory due to security issues (which they felt was “alarmist and counter-productive”). Their message read in part:

We do not release details where possible of security issues before a fix is available. Given what you do I am sure you know this is the correct behaviour.

At the time we were flabbergasted by that, not only because they wrong, but they thought that it was obviously the right position.

Here are some of the reasons that this position is so misguided:

The Details Are Often Are Already Public

What makes hiding the fact that a plugin has a vulnerability seems so obviously misguided is that in many instances (maybe most of them) the details of the vulnerability have already been publicly disclosed. The people running the Plugin Directory are well aware of that fact just based on how often we notify them of public disclosures of vulnerabilities that are in the current version of plugins in the Plugin Directory. Hackers are already likely to know about those public disclosures, so letting people with the plugin installed know of them as well shouldn’t do much to increase the hacker’s knowledge. By comparison the average webmaster of a website using them is unlikely to know about those disclosures, so you are greatly increasing the chances that they can do something about it by notifying them, while not increasing the chances of exploitation by hacker by very much.

It Can Be Incredibly Easy To Figure Out Where a Vulnerability Exists

But what about a situation where the vulnerability hasn’t been publicly disclosed? The claim by WordPress is that “If we don’t tell anyone, then hackers who DO know will attack, but they would have anyway.” It doesn’t seem to be a good idea to us to keep quiet about vulnerabilities so that only some hackers can exploit your website, instead of making you aware of the issue so that you could remove the plugin and prevent anyone from hacking it.

What make this more problematic is that from recent experience we have found that it can be very easy to find an exploitable vulnerability by just knowing that other people are trying to exploit a plugin. Starting in early May we started getting requests on our website that seemed to be people looking for usage of plugins for which there were not known to have vulnerabilities. In all but two instance so far we were able to quickly find security vulnerabilities that are the kind that hacker would try to exploit. In one of the instances where we didn’t find a vulnerability that a hacker was would try to exploit looks like the hackers might have been trying to target a vulnerability that wouldn’t normally be exploitable and in the other the code was so insecure that we couldn’t narrow down where to look (but we did find two vulnerabilities that were less likely to be exploited).

In many of the cases we able to find these vulnerabilities in a matter of minutes. If we can do that you can be sure that people that are actually trying to hack website could do that as well.

Vulnerabilities Are Not Always Fixed in A Timely Manner, If At All

It would be one thing if WordPress withheld their knowledge of vulnerabilities for several days while a fix for the vulnerability was being put together. But as they are well aware it can be months before a developer gets around to fixing a vulnerability. For example, the plugin SEO Redirection, which has 60,000+ active installs according to wordpress.org received a fix for a vulnerability that was disclosed at the end of March in the middle of June (that plugin was then removed from the Plugin Directory again, but then returned without it being fixed). The developer didn’t even have to come up with fix since the disclosure include a proposed fix, which they used. In another case we looked at last year it took two months for a vulnerability in a plugin with 200,000+ active installs to be fixed despite requiring less than a line of code to fix.

In other cases vulnerabilities that hackers are known to be exploiting are never fixed, for example the plugin Plugin: Newsletter has an arbitrary file viewing vulnerability that was disclosed in May of 2012 that was never fixed and we continue to see attempts to exploit it. So when the WordPress folks say they won’t release details of vulnerabilities until they are fixed they are in fact saying is that they are fine with the possibility of keeping the public in the dark forever about the vulnerability.