The Data in the WPScan Vulnerability Database Is Definitely Not Confirmed/Validated
Among the many lies told by the company behind the very popular WordPress security plugin Wordfence Security, Defiant, one that really stands out to us personally is a lie they told that relates to something that as far as we are aware we uniquely do when it comes to collecting data on vulnerabilities in WordPress plugins. In response to a complaint about the data they use in trying to tell people if an update to a plugin is a security update they claimed to rely on “confirmed/validated” data for that. In truth their source, the WPScan Vulnerability Database, explicitly notes that they haven’t verified the vulnerabilities in their data set. As far as we are aware we are the only ones that actually do the work it takes to confirm and validate vulnerabilities, which provides our customer with higher quality data and doesn’t leave them unaware that vulnerabilities haven’t actually been fixed. We recently ran across an instance of where the WPScan Vulnerability Database clearly didn’t do that work, where we had at first thought that maybe we had missed something that we should have noticed.
Back on October 29 we wrote a post detailing an authenticated persistent cross-site scripting (XSS) vulnerability in the plugin AMP for WP – Accelerated Mobile Pages, which had been fixed, but the plugin was closed on the Plugin Directory, so it wouldn’t have been easy to update to a fixed version (though we were available to help our customer do that). Then on November 5 we noted that hackers look to have already started probing for usage of the plugin, which was a concern since the plugin still had not been restored to the Plugin Directory.
It wasn’t until November 13 that he WPScan Vulnerability Database had added a listing that appeared to be related to that:
What was different is that they are claiming that this involves “Unauthenticated” vulnerabilities. That could potentially be of much more concern, since the number of attackers that would be able to authenticate, that is log in to WordPress, would be much smaller than could access websites using the plugin, so depending on what they could do that could be a bigger issue. What it was they were claiming was at issue, was clear as mud since there were zero details provided. So had they found something we missed or did they just publish inaccurate information and have no idea if it was accurate? If you look at the listing you can see it is not “Verified”, so it seems possible they had no idea if the information was accurate (we can’t recall every running across a listing where it was listed as being verified).
In looking at some information for another post or two, we came across an answer, the vulnerabilities they are referring to are all ones that are claimed to require authentication. The person they cite as the source of these vulnerabilities wrote this when notifying the Plugin Directory about the issues:
All this can be done with merely a WordPress subscriber/visitor/commenter account.
These hooks lack nonce and current_user_can() verifications, and wp_ajax_* actions only require the user to be logged in.
That is a good reminder that if they you are looking to keep track of vulnerabilities in WordPress plugins you use, our service is really worth since the WPScan Vulnerability Database was not only providing inaccurate information, but it took them two weeks to even get around to providing inaccurate information. By the time they did it looks like hackers might already have been trying to exploit this plugin for over a week.