Wordfence Falsely Claims Their Data Source on WordPress Plugin Vulnerabilities is “Official” and “Confirmed/Validated”
When it comes to getting data on vulnerabilities in WordPress plugins there appear to be a lot of sources, but in reality most of the time it is really comes from the WPScan Vulnerability Database. While we think that that data source is a good option for a lot of people since it is available for free, you do get what you pay for. And anyone reusing that data should be upfront about the real source of the data and alert people to the serious quality control issues that come along with it.
Considering that people behind the Wordfence Security plugin don’t seem to have any qualms about lying no matter how blatant the lies, it wasn’t surprising to see they have gone beyond not providing the proper disclosure of their use of WPScan’s data to making false claims that make it sound like it much better than it really is. We just ran across them giving their usage an imprimatur as being from an “official” source and falsely claiming that the data is “confirmed/validated” when neither of those things are true about the WPScan’s data.
In a recent thread on the wordpress.org Support Forum, which we ran across in our monitoring to keep track of vulnerabilities in plugins for our service, someone wrote:
Hello,
We’re noticing an increase in the amount of plugin updates that are not being marked as “Security Fix” in our wordfence emails (“Problems found on http://www.example.co.uk“).
The most recent occurrence of this was the uk-cookie-consent plugin.
This updated from 2.3.9 to 2.3.10 after a security vulnerability was patched.Changelog:
2.3.10
Fixed: fixed security vulnerability identified by James BougheyWe maintain a large client base and rely on these emails to quickly determine if the update needs to be applied immediately (Security related) or if it can be put on hold temporarily (Feature update).
Kind regards
First, we should note that trying to decide whether to update a plugin based on data about what plugin vulnerabilities is a very bad idea, since even if you are using a better data source that the WPScan Vulnerability Database it isn’t going to provide the level of coverage of vulnerabilities needed to try to pick and choose what plugins to update. That is why in addition to providing a service with better data, we also have a plugin that will turn on WordPress built-in ability for plugins to automatically update.
Update 5/4: We should also note that one reason why someone might think that trying to choose when to update plugins based on claims that they have a security issue is something that is not a bad idea is Wordfence’s postings about vulnerabilities in plugins.
In this case it actually would have been correct for Wordfence to not mark this as a “Security Fix” since, as we discussed last week, the claimed vulnerability that was supposed to be fixed in that version didn’t actually exist.
The response from a Wordfence employee was this:
We do mark plugins as being vulnerable when we know for certain they are.
Unfortunately we can’t rely on authors’ changelogs for detecting vulnerabilities, because there are too many inconsistencies (for example, they might mention “security hardening”, which isn’t necessarily a vulnerability fix) and some authors maintain changelogs outside of wordpress.org or commit changelogs in a non-standard way.
Once a vulnerability is officially confirmed we update our servers’ list of known vulnerabilities which then allows scans to accurately report the issue.
I confirmed the “UK Cookie Consent” plugin now shows a critical scan result with a link about the security fixes for version 2.3.9 -> 2.3.10.
Contrary what is written there, Wordfence doesn’t actually have any idea if a vulnerability actually exists when they mark them as such. By “officially confirmed” they are actually referring to a vulnerability being listed in WPScan’s data, which isn’t official in any way, nor is there any official confirmation out there. (We confirmed that is their source by comparing WPScan’s data to what Wordfence is marking as including security fixes and we have also previously seen more obvious usage of WPScan’s faulty data by Wordfence.)
The ease that Wordfence lies about things continues to be stunning to us. That they not only get away with it, but that public comes up with excuses for them doing that, is a good example of why security is in such bad shape.
What makes this worse is that if you actually look at WPScan’s data for that claimed vulnerability they specifically note that it isn’t verified:
So the vulnerability isn’t actually confirmed even unofficially.
In a follow up reply the Wordfence employee had made further claims:
It’s not that we perform specific checks on our side, rather we update our list of known vulnerabilities by pulling information from an official source; our servers are updated at least once a day.
Sometimes a plugin author fixes a vulnerability that hasn’t been reported yet and in such case official sources for vulnerabilities do not report the issue.
Regarding the time frame; again it all depends on when the security issue gets confirmed/validated. We have no control over that.
Again, there is no official source. It obviously sounds impressive though, which seems to be the point, and they rightly assume that most people wouldn’t bother to question something like that.
Also, contrary what is claimed there, there is no reason that Wordfence couldn’t have control over confirming/validating vulnerabilities in WordPress plugins, but that would require doing some actual work. And why would they when they can get away with claiming to provide the “best security available” for WordPress websites while failing to even do the things actually claim to do.
That WPScan’s data include vulnerabilities that don’t exist is much less of issue than other problems including incorrectly claiming that vulnerabilities have been fixed when they haven’t (which we will be discussing a couple of examples of in an upcoming post), but also that they are missing a lot of vulnerabilities that are being exploited (including ones where there isn’t a fix), which you would be warned about by us even if you don’t use our service (through use of the service’s companion plugin).
If you are actually interested in getting the most complete data on vulnerabilities in WordPress plugins, with all of the vulnerabilities actually confirmed/validated, that is exactly what our service provides. We have been told that Wordfence doesn’t admit to people that our service or any like it exists if they contact them looking fro that, despite them admitting they were aware of us after someone called them out on the claim that no service like ours exists.