19 Oct

Not Surprisingly, Attacking The Messenger Didn’t Resolve a Problem With a WordPress Security Plugin/Service

We are always looking at how we can improve the service that we provide to our customer. One of the ways we do that is by looking at how we compare to products and services that product similar functionality. Back in March we took a look at a plugin named Security and Vulnerability Shield, which connects to the plugin developer’s service to provide data on vulnerabilities in WordPress plugins. At first glance the service behind the plugin sounded impressive, but looking a little deeper we were left wondering as to the veracity of claims made by the developer.

At that point we wanted to see if looked like they were even collecting their own data or if they had in fact copied their data from another source, but we found that the plugin only told you if the currently installed version was vulnerable. That meant we couldn’t use other common data, like the type of vulnerability and a URL with more information on the vulnerability, to see if that information was identical to other sources of data. That also limited the usefulness of the plugin/service, as those details can rather important. For example, if the vulnerability hadn’t been fixed yet, the type of vulnerability and the specific details could tell whether the plugin needs to be removed right away or if it is of little concern.

The much larger issue we found was that it didn’t look like their data wasn’t being updated anymore, as none of the plugins for which we had added vulnerabilities to our data in the last month were being listed as being vulnerable by their service.

Due largely on the fact the data wasn’t being updated anymore (and to a lesser degree due to the lack on details on the vulnerabilities), we ended the post say that “this plugin doesn’t seem to be a good option at this point”.

We also created a thread in the plugin’s support forum letting people know that the plugin’s data source didn’t look to be being updated anymore, seeing as they would have no other way of knowing that.

The Developer Responds

Two weeks later the developer responded in the thread acknowledging that the data source was not being updated.

They then moved on to making a claim that seemed false at the time and nothing since then has pointed to it being true:

currently we are not providing updates to our database, because of major upgrade in our service and plugin.
Our goal is to double the number of vulnerable plugins data that we’d captured…

Considering that the that when the plugin was released they already were claiming scan for more than “3000+ known vulnerabilities and exploits”, doubling the number didn’t seem like an honest explanation of what was going on (by comparison another database that contains plugin as well as theme and core WordPress vulnerabilities currently only has 5,200 entries). It also didn’t make much sense that doubling the amount of data would somehow stop you from adding the latest vulnerabilities. The plugin also had not been updated to indicate that it was compatible with newer version of WordPress, which wouldn’t have required a major changed, so it seems more like it wasn’t being actively developed anymore.

It seems to us things should have ended there, but then the developer started criticizing us. Their first post of this was (it should be noted that the quoted portions, are not actual quotes):

We’d googled a bit and … we’re not really happy with the approach you are having towards sites/services/plugins which are somehow in a competition with the ones provided by your company.

As a result of your actions, a lot of people would be misguided and in a risk of NOT using plugins, services, sites or other companies, which can help them mitigate risk for their websites.

It is VERY misleading to just say: “Hey, you don’t have data for those X plugins”.
The importance and the value of our plugin (and dataset) can’t be measured by just checking X plugins.

Last, but not least. This behaviour (randomly posting “this does not work! stop using it!” for 3rd party plugins and sites (from what we’d seen by simply googling “White Fir Design”) that are a competition to your plugins and services with the idea to advertise your own product is a very, very, very childish, misleading for the users and unprofessional.

We still are not clear what was supposed to be the problem as as our suggestion that their plugin was not the best option was largely based on the data not being updated, which they had confirmed (we do write post detailing problems with security products and services, but based on issues detailed in the post, not just “randomly posting this does not work! stop using it!”).

It then continued in another post:

Telling someone to use your plugins, instead of someone else’s, because our plugin does not have plugins X and Y flagged as vulnerable is misleading.

They should never rely on a single point of truth, so when we get asked for should a user use only our plugin or disable other plugins, we always recommend that they should use not only our plugin, but others also.

So, since you are apparently doing the opposite, can you give 100% guarantees to your users that your database contains ALL possible/known vulnerabilities out there, so its totally ok for them to not use other security related plugins like ours?

In an unfortunately all to common occurrence, what was said there seems to have little relation with the truth. The part that really sticks out is when they said the “always recommend that they should use not only our plugin, but others also”, as it seems unlikely that they ever had been asked that. There is nothing along that lines in the support forum for the plugin, the plugin only currently has 800+ active installs so the chances that many people would have contacted them privately would be low, and we don’t even know how they could contact them, as their website simply consists of a homepage with the word “home” on it. (We also had not told anyone to “use your plugins, instead of someone else’s, because our plugin does not have plugins X and Y flagged as vulnerable”).

It also isn’t to uncommon an occurrence for security companies to not handle legitimate critiques by working to fix the problems instead of going after whomever pointed them out.

Still Not Being Updated

It has now nearly seven months since we made our recommendation that the plugins was not a good option, so considering the amount of criticism we got from the developer, we wanted to see if we had made a mistake. The plugin itself hasn’t been updated since that all went down, it is still only listed as being compatible up to WordPress 4.3. But the big question was if the vulnerability data was being updated again. We loaded up all the plugins we added vulnerabilities for in the month of September in to a fresh WordPress installation to check.

As you can see all of these plugins are listed as having vulnerabilities by our plugin/service:


With the Security and Vulnerability Shield plugin activated you can see that none of them are listed as containing vulnerabilities:


Not surprisingly, going after us for pointing out the problem didn’t do anything to resolve the problem.