When it comes to companies with security products and services we continue to run across new bad things they have come up with to push their products.

A couple weeks ago a company made the following claim:

Until now, it might have been impossible for a regular user to know how to find a bad plugin, but that’s where we step in to help you.

That was in regards to a page they had created with a list of vulnerabilities in WordPress plugins, which they had taken directly from the companion plugin for our service. So not only were they lying about it not already being possible of checking for bad plugins, but they had come up with a way to make it much harder to check if a website was running a vulnerable plugin, than if they had just let people know about the plugin. Why do that? To promote their security plugin.

The latest involves the company WP Media, which is behind SecuPress, as well as a caching plugin WP Rocket. Two weeks ago we look at the fact that through the SecuPress blog they were falsely claiming a vulnerability in a competing caching plugin, W3 Total Cache, was “high risk”.

An interesting follow up to that is that after someone else also pointed out the vulnerability isn’t “high risk”, someone from SecuPress responded thusly:

Hello Rob, you can’t just say “it’s a very low risk” just because of the user range.

Can you give us your full scoring for this vuln?

Thank you

First off this reinforces our belief that that severity scores being push by security companies are largely about making them appearing more professional than they really are. In this case the score provide SecuPress that was supposed to back up the claim that the vulnerability was “high risk” was built largely on subjective decision by them, which happened to be false. So the claim that it was “high risk” relied on little more than what they are saying isn’t acceptable to say it is “very low risk”, the only difference being they wrapped their claim in a severity score.

That wasn’t enough for WP Media and SecuPress, as they have put out another post claiming to have found four more vulnerabilities in the plugin, including two “high risk” ones. The reality is that three of the vulnerabilities, if you were consider them vulnerabilities, would only be exploitable to Administrator level users and would be things that those users would be normally be able to do. They would probably be better describe as bugs, since they are things they don’t allow the users to do something they normally wouldn’t be able to do. But in any case they way they are portrayed in the post makes them sounds like a serious threat when they decidedly are not.

The first claimed vulnerability is the only one that looks to be real and it only allows you empty certain caches if you happen to get “lucky”. SecuPress rates it a “low risk”.

Then you get the to the non vulnerabilities. First up, being a claimed “high risk” file upload vulnerability and here they start with the over the top language:

Reading the vulnerability name is already harmful for me. Yes, you can upload files in W3TC support form.

The problem with this being a vulnerability is that Administrator level users normally can upload arbitrary files through the ability to upload new plugins (lower level users can upload a limited set of files types). The post actually has a response to this, but it is misleading:

An administrator is not always allowed to execute custom PHP code, he’s not the webmaster but a WordPress administrator, so this represent a vulnerability.

It is true that an Administrator is not always allowed to execute custom PHP code, but they normally would be able to do that by adding a new plugin:

or editing a plugin’s file:

or editing a theme’s file:

Could someone disable an administrators ability to access those things, sure, but it doesn’t look to be a common thing to do that without Administrators being able to re-enabled those things. SecuPress doesn’t provide any evidence that it is in fact common.

The same basic claim is made for the next vulnerability, a “low risk” file download vulnerability:

Pointing on the files.php URL you can now download the wp-config.php, because for the same reason as before, an administrator is not always allowed to read the config file, he’s not the webmaster but a WordPress administrator, so this represent a vulnerability.

Again normally they would be able to, you could for example install a file manager plugin and view the files on the server.

If a webmaster is trying to restrict someone from being able to do those thing as a WordPress user, it would make more sense to make them a lower level user than to restrict the Administrator level user in that way.

The final claimed vulnerability, a “high risk” PHP eval, doesn’t make much sense. If you are ability to upload arbitrary files than you could upload a .php file and have it run. Yet someone how this is worst:

The worst for you is to allow a user, even an administrator, to eval any PHP code.

The section on it ends:

Basically we can send a PHP script that will create a backdoor.

Again we are talking about something that can only be done by an Administrator, if you have a malicious Administrator you have a whole host of other problems before you get to any issues with vulnerable plugins.