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”. [Read more]

One of the things we do to provide our customers with the best data possible on vulnerabilities that impact the WordPress plugins they use, is monitoring our websites for hacking attempts. For the first few months of the service we were seeing attempts to hack vulnerabilities already included in our data and very old vulnerabilities that we didn’t yet have in our data. Starting at the beginning of May we started seeing what looks to be requests from hackers probing for usage of plugins that we could not find any public disclosure of a vulnerability or any indication in the changelog that a vulnerability that hackers might be interested had existed and the been fixed in the plugin. When that occurs we quickly try to find if there is vulnerability that exists in the current version of the plugin that hackers would be interested in. In most cases we are able to find something that if hackers are not already exploiting, then they would exploit if they were to become aware of it (by comparison many vulnerabilities discovered in plugins are ones that are very unlikely to be exploited on the average website).

Seeing as we often find those vulnerabilities in a matter of minutes, those vulnerabilities are a good reminder that the security of WordPress plugins is not in great shape at this point. While some developers are quick to respond with a new version of the plugin that fixes the vulnerability, all to often fixes take weeks and in many cases the plugins have yet to be fixed. All of that is contrary what you might hear from people closely connected to WordPress. [Read more]

When it comes to improving the security of WordPress plugins one big problem we see is that it is hard for the community at large to have a good understanding of what the real issues are and therefore push for the needed changes, because security companies put out so much misleading information. We often see security companies discussing vulnerabilities that is of a type that is very unlikely to be exploited, and instead of mentioning the limited threat, they instead only mention the worst case scenario. That isn’t helpful and it does have a negative impact, as we see people thinking that they have been exploited by these types of vulnerabilities when they clearly were not. Another issue we sometimes see is that security companies will exclude important information on the limitations of vulnerabilities, for example we repeatedly spotted Wordfence excluding any mention that vulnerabilities they were discovering were only exploitable when logged in to WordPress, which limits the chance of exploitation by a large degree and is important to mention since it allows many webmasters to immediately know that the vulnerability could not have impacted their websites before it was fixed.

Because press coverage of security is often little more than repeating claims of security companies, who are in turn putting out misleading information, you end with sensationalistic coverage that provides little value. [Read more]

One of the issues we sometimes spot when reviewing reports of vulnerabilities in WordPress plugins is that the vulnerability has been fixed but the version number of the plugin has not been increased. That means that people downloading the plugin at that point will be secured against the vulnerability, but anyone who already had the plugin installed will still be vulnerable since there is no new version for them to be prompted to up date to. While it easy thing to resolve we have found that sometimes even after contacting the developers they won’t bump the version number. Why that is, is a mystery to us.

Not only is this a security issue, it also violates the Developer Guidelines of the Plugin Directory, specifically guideline 15: [Read more]

When it comes to getting security vulnerabilities in WordPress plugins fixed far to often it takes having the plugin removed from the Plugin Directory for that to happen. That removal will only happen if the Plugin Directory is made aware of the security vulnerability. From being the ones that have reported many of those vulnerabilities to them, due to our discovery of plenty of vulnerabilities and our monitoring of publicly disclosed vulnerabilities, we have seen that response times are not good. Often it takes them days to process the requests and that means additional days until the problem gets resolved.

For most of those vulnerabilities the chances of them being exploited are pretty small, so the delay in getting them resolved is not a major concern. But what about when a plugin is being actively exploited and there are serious security vulnerabilities in the latest version of the plugin? The response time isn’t better. [Read more]

In monitoring vulnerabilities in WordPress plugins one problem that we have noticed, which if fixed could improve the security of plugin, is the difficulty the public has in knowing where to report a security issue in a plugin on the Plugin Directory.

To show that this is an issue, here a couple of examples we ran across recently showing that people that have discovered vulnerabilities have not found the correct place to report them: [Read more]

When it comes to cyber security there is a lot of bad information out there and when it comes to information about WordPress security, it is at least as bad, if not worse than average for cyber security. One piece of bad information we see when it comes to security of WordPress plugins is the assumption that vulnerabilities in WordPress plugins are promptly fixed, so as long as you keep your plugins up to date you are okay. The reality is that while many are fixed promptly, there are plenty more that don’t get fixed promptly or never get fixed.

To you give some idea of what that means in the real world we went back through the weekly posts we put out detailing what have been doing and adding to the service during each week and found all of the plugins with vulnerabilities that are still removed from the Plugin Directory due to the security vulnerabilities (plugins are removed from the Plugin Directory after the people running it are notified that a plugin has a security issue in the current version of it, with many of those notifications coming from us). [Read more]