Wordfence Isn’t Telling the Truth About the Sourcing and Reliability of Their Plugin Vulnerability Data
As we have documented multiple times before, Wordfence is providing highly inaccurate information on vulnerabilities in WordPress plugins. We keep running into more examples of that. Earlier this week someone contacted the developer of a plugin about Wordfence’s claim that there was a vulnerability in their plugin, where things very seemed off:
The Wordfence plugin reported that the plugin has a security vulnerability. When I look at this page https://www.wordfence.com/threat-intel/vulnerabilities/wordpress-plugins/iubenda-cookie-law-solution/iubenda-357-reflected-cross-site-scripting its shows the problem is fixed with version 3.5.8. But the version on wordpress.org is only 3.4.1
How could a vulnerability be fixed in a version that doesn’t yet exist?
As explained by the developer, Wordfence had somehow mixed up the plugin with a completely unrelated plugin:
we are investigating the report, and we are trying to keep in touch with Wordfence support: at first sight, it seems related to another plugin (not our plugin).
In fact their reference link leads you here: https://plugins.trac.wordpress.org/changeset/2840328/blockonomics-bitcoin-payments/trunk/blockonomics-woocommerce.php
The developer was then having to deal with the fallout of Wordfence’s mistake, as has repeatedly happened since they created their own data set.
Someone recently left a negative review of Wordfence’s Wordfence Security plugin over what they claimed was them lying about the security of another plugin. As the example above shows, it is certainly true that they are spreading false information about the security of plugins. The review didn’t provide specifics of what was at issue, so we don’t know if that was true or not. That review has now been deleted (the moderators of the WordPress support forum have a history of deleting criticism of Wordfence, while frequently promoting them).
In response to that, Wordfence’s Lead Customer Support Engineer, Tim Cantrell (or Mia), someone who has a history of dishonestly responding to legitimate criticism of the company, responded to that this way:
Well, it’s rather hard to explain it if you haven’t bothered to mention what plugin you were alerted about. And just because you don’t believe something doesn’t make it a lie. The feature you are upset about checks other respected CVE issuers (where vulnerabilities are reported) in addition to ours and lets users know if one of their plugins or themes has a vulnerability listed for their version. If the CVE that reported it is Wordfence, then the plugin or theme does have a vulnerability and if you open a support ticket we’ll be happy to explain what it is and what version fixes it. If the plugin or theme is reported to another CVE issuer that we check then we also let you know where to look up the information about it. We believe that it is your right as a webmaster to have all the information you need to make informed decisions to protect your website. Site owners owe it to their site visitors and customers to provide a site free of malware, phishing, and spam. If you want, you can always choose to ignore the issue in your scan results and you won’t be told about it again. The choice is entirely up to you.
There are glaring problems with that.
One problem is that much of Wordfence’s data doesn’t come from CVE. That was the case with the false claim of a vulnerability we mentioned earlier in the post, where there was no CVE cited in their entry before it was deleted:
This isn’t the first time Wordfence hasn’t told the truth about where they get data, as before they created their own data set they were falsely claiming to relying on “official” and “confirmed/validated” data while relying on another unreliable source.
Another problem is that the entity mentioned there, CVE, doesn’t take responsibility for the accuracy of data in their system, saying that the entities they allow to submit information, CVE Numbering Authorities (CNAs), are responsible for it. They don’t restrict who can enter information to respected companies, as Wordfence would like you to believe. It looks like just about anyone is allowed to enter things into their system. They also don’t have a mechanism to report that providers that are systematically entering inaccurate information. That all leads to highly inaccurate data, making CVE an unreliable source.
As an example of what you end up with when relying on CVEs data. Two months ago we ran across a false entry in their system claiming a WordPress plugin with 800,000+ installs had an unfixed vulnerability. When we contacted the CNA, VulDB, about that, they stated that not only hadn’t they done basic work to confirm whether there really was a vulnerability, but also that they thought they shouldn’t be expected that they should do that work. That is a company who Wordfence is treating as a reliable source.
Wordfence should either verify all claims about vulnerabilities before passing them along to their customers or they should state that the information isn’t reliable, which is possible to do, as we do it with our data set. Doing otherwise runs against Wordfence’s stance that they “believe that it is your right as a webmaster to have all the information you need to make informed decisions to protect your website”.
Another problem with this is that not only is Wordfence not telling the truth here, or in so many other situations, but they market themselves, as can be seen by the top of their website’s homepage, as being trustworthy despite that not being the case:
