Last week we wrote a couple of posts about Wordfence, the second one was based on a claim we noticed while working on the first. That leads to this post, which is based on a claim we saw while working on the second post.

In a post about vulnerability in a plugin from earlier this month (in which the discoverer of the vulnerability conspicuously wasn’t mentioned) Wordfence said people using their product were already protected against that vulnerability “because Wordfence has built in protection against stored XSS attacks”. That unqualified claim that there product can protect against such a broad type of vulnerability doesn’t sound like something you would hear from a responsible security company and when it comes to this type of vulnerability, which we refer to as persistent cross-site scripting (XSS), it sounded unbelievable.

To understand why it sounded unbelievable it it is important to understand what persistent XSS is. It is the storage of some form of malicious code on a website, most often that code would be JavaScript code. Since JavaScript is integral part of websites these days, just being able to store JavaScript isn’t a vulnerability. In WordPress for example, users with the role of Editor or Administrator normally have the unfiltered_html capability, which allows them to use “JavaScript code in pages, posts, comments and widgets”. Throw in the fact that persistent XSS vulnerability might involve inserting JavaScript code into the middle of some existing JavaScript code and it is hard to believe that it would be possible to do what Wordfence was claiming.

If Wordfence had said they could protect against that particular vulnerability or some of this type vulnerability it would be a different story.

To see if Wordfence was on the level with their claim or if they were again making a claim not backed up by reality, we did a simple test. We installed their plugin, enabled the firewall (with the Enabled and Protecting status), and tried to exploit the newest persistent XSS vulnerability we had discovered at the time. The vulnerability in the Cherry Plugin allows anyone logged in to WordPress to turn the plugin’s maintenance mode on and have the maintenance page serve JavaScript code specified by the attacker. We would say that this type of vulnerability isn’t a major threat since it requires to be logged in to WordPress and on many websites it would be very difficult for an attacker to do that, but Wordfence seems to think that limitation isn’t even important enough to mention when they disclose vulnerabilities, as we have found when we looked at four recent vulnerability disclosures they made.

Since the vulnerability existed in the current version of the plugin and as far as we are aware we are the only one that have noticed it so far, it seemed to be a good test if Wordfence provided some value, as people would otherwise completely unprotected against this.

We when submitted the exploit we got a blank page back, which would occur if it was successful:

The looking at the homepage when not logged in, we found the persistent XSS exploit was successful:

So Wordfence didn’t actual prevent a real world persistent XSS vulnerability from being exploited.

The question we are left with is whether Wordfence doesn’t understand security enough to know the limitations of their product, they feel that they don’t need to be responsible when making bold security claims (which is all to common among security companies these days), or if they just feel it is appropriate to outright lie to public. In any case it is yet another reminder of the really poor state of WordPress security companies these days.