From what we have seen recently, the Wordfence company has a habit of saying things that are not true, from claiming a WordPress plugin vulnerability had been fixed when it wasn’t, to claiming their Real-Time Threat Defense Feed has “unmatched access to information about how hackers compromise sites” while not detecting vulnerabilities being exploited in the current version of plugins that we easily detected, to claiming that their firewall provides blanket protection against persistent cross-site scripting (XSS) while not actually catching real world exploit attempts. With noticing all that in just the past few weeks the latest situation isn’t all that surprising, but is worth noting, since at best they are putting out bad information and at worst they are trying to credit for discovering vulnerabilities in a plugin that had already been fixed when they claimed to have contacted the developer about them.

On July 6 Wordfence posted about three vulnerabilities they had discovered in the WP Maintenance Mode. They claimed that version 2.0.7 “included fixes for 3 security vulnerabilities”, and the title of the post indicates that the vulnerabilities existed in “2.0.6 and older”. The post also states that they “notified the plugin author last week”, which would mean that they notified the developer on June 26 at the earliest.

When we went to look at the vulnerabilities to add them to our data, we quickly found the changes related to fixing the authenticated remote code execution (RCE) vulnerability in version 2.0.7. We couldn’t find any changes that look related to the other two vulnerabilities. But based on the description we were pretty sure where the issue would have been, but found that the proper security was in place to protect against them 2.0.6. When we went and looked back to older versions we found that vulnerabilities had in fact existed from version 2.0.0 to 2.0.3 and had then been fixed in version 2.0.4.

Version 2.0.4 was release on June 17, which is more than a week before Wordfence claims to have contacted the developer about the vulnerabilities.

The changelog for 2.0.7 credits Wordfence for two items:

• reset_settings _wpnonce check (thanks # Wordfence)
• modules > google analytics code sanitization (thanks @ Wordfence)

The first is something that Wordfence didn’t bring up in their post and the other refers to the authenticated remote code execution vulnerability. The changelog for 2.0.4 doesn’t mention Wordfence or even mention anything that appears to be related to the vulnerabilities fixed.

In the best case, Wordfence actually reported all of the vulnerabilities and then incorrectly listed what version was vulnerable and when they contacted the developer. That wouldn’t be a huge issue, but with so much of security being about trust and considering their track record we would probably recommend avoiding them based on that track record alone. It would much more of an issue if they are taking credit for vulnerabilities discovered by someone else.

We Always Verify Data Before Adding It To Our Service

When we add vulnerabilities to the data set for our service we test it out first so that we can insure the vulnerability existed (there are more than a few false reports of vulnerabilities), that it has actually been fixed (many times we find that a vulnerability has not been fixed, despite a claim that it has), so that we can let you know what version are vulnerable, and so that we can accurately label the vulnerability. Other similar data sources don’t do any testing, so for example in this case, if you use a plugin or service that uses data from WPScan vulnerability database you are incorrectly told that those two vulnerabilities existed up to version 2.0.6 and were fixed in 2.0.7 (you also are not told which other versions were vulnerable):

While that has a limited impact in a case where the vulnerability has been fixed, since most people are probably just concerned about being protected now that the vulnerability has been exposed, but in other cases they will falsely claim that a vulnerability has been fixed when it hasn’t.