In reviewing reports of vulnerabilities in WordPress plugins to provide our customers with the best data on vulnerabilities in plugins they use we often find that there are reports for things that don’t appear to be vulnerabilities. For more problematic reports we release posts detailing why the vulnerability reports are false, but there have been a lot of that we haven’t felt rose to that level. In particular are items that are not outright false, just the issue is probably more accurately described as a bug. For those that don’t rise to level of getting their own post we now place them in a weekly post when we come across them.
This post provides the details of a vulnerability in a WordPress plugin not discovered by us, where the discoverer hadn’t provided the details needed for us to confirm the vulnerability while we were adding it to the data set for our service, so its contents are limited to subscribers of our service. If you are not currently a subscriber, you can try out the service for free and then you can view the contents of the post. There are a lot of other reason that you will want to sign up beyond access to posts like this one, including that you would have already been warned about this vulnerability if your website was vulnerable due to it.
When it comes to the chances of vulnerabilities being exploited the reality is that many types of vulnerabilities are highly unlikely to have anyone even try to exploit them. Unfortunately far too often we see security companies and the press making a big deal of vulnerabilities that are are of little to no threat, while ignoring vulnerabilities and broader security issues that are leading to websites being hacked (that lead us to providing information on likelihood that a vulnerability is to be exploited to the data for our service). When it comes to types that are likely to be exploited, the arbitrary file upload vulnerability, which allows a hacker to upload files of any kind to a website, is probably the one with the most exploit attempts and also then ends up leading to the most websites being hacked. So if a WordPress security plugin is going to protect against any type of vulnerability this seems like this is the one you would most want it to be able protect against.
Recently we started testing to see what protection WordPress security plugins provide against vulnerabilities in other plugins (since plugins vulnerabilities are an actual source of websites being hacked, unlike some other things that these plugins make a big deal or providing protection against). The first vulnerability we tested could be used for serving up malware on a website and the second could give an attacker control over the website. Both of those are types of vulnerabilities that are the kind that are often thought of when discussing the security of websites, for example the very popular Wordfence plugin is advertised as “protecting your website from hacks and malware”. Not every security issue though falls into those categories. As you can guess from the name, an information disclosure vulnerability involves the disclosure of information that isn’t intended to be public and those can be a serious issue. For example, if you run an eCommerce you wouldn’t want your customers’ details to be accessible by the public.
Last week we did our first test to see what protection that WordPress security plugins can provide against the exploitation of the vulnerabilities in plugins. The results for a persistent cross-site scripting (XSS) vulnerability were not good, with only 2 of the 11 plugins tested providing any protection and even the protection in those two was easily bypassed.
In the past few months we have done several one off tests of WordPress security plugins to see if they could prevent exploitation of a vulnerability in a plugin. We tested an extraordinary claim by Wordfence that their plugin could prevent persistent cross-site scripting (XSS) and found that it failed both with a vulnerability that required authentication and one that didn’t. We also tested the iThemes Security security plugin against an arbitrary file upload vulnerability that we have found was being exploited in another plugin by one that plugin’s developers and it also failed to prevent exploitation.