We used to say that the WPScan Vulnerability Database was good source of data on vulnerabilities in WordPress plugin for the price, considering that it is low quality data, but accessible for free. Over time though the quality has gone further down and the people behind it seem to be unconcerned with the truth, with is kind of important when it comes to security.
When it comes to getting data on vulnerabilities in WordPress plugins what we have noticed is that many sources are not using unique data, but instead reusing data from another source, often without letting people know what the true source is and never with a disclaimer about the quality issues that are inherent in that data source. That source is the WPScan Vulnerability Database, but recently we realized that they in fact are often just copying their data from yet another source. That source being the Common Vulnerabilities and Exposures (CVE) system. As we have more closely monitored that source recently we have noticed plenty of issues with it. This week we noticed something that wasn’t as much concern, but does present a worse picture of the WPScan Vulnerability Database.
Recently we have had a number of instances where developers of WordPress plugins incorrectly claimed that we had falsely claimed there was vulnerability in the most recent version of their plugins. Since we are well aware of what kind of problems that getting that wrong cause, we are very careful with what we do and say, so it would be very difficult for us to make a false claim like that. Others seemingly are not concerned about doing the same, so for example, another data source, the WPScan Vulnerability Database is claiming a vulnerability that had been in the plugin JTRT Responsive Tables hasn’t been fixed, despite that having been fixed before they even added it to their data set and despite it being fixed over a year and half ago. That is something we ran across recently in our monitoring of the WordPress Support Forum for information on vulnerabilities in plugins that our not already in the data set for our service.
In a previous post today we noted how our service can be useful for figuring out how WordPress websites have been hacked. It obviously would be better to avoid being hacked in the first place and our service also helps with that, but there are limits to that. If hackers are the first to find vulnerabilities then we are going to only be able to notify our customers after that, though we may be able to notify them before the vulnerability can be exploited on their particular websites. With other data sources, the results of even being able to provide information after the fact is limited, as can be seen with the very popular, despite being of rather poor quality, WPScan Vulnerability Database.
W3 Total Cache is one of the most popular plugins in the WordPress’ Plugin Directory, with 1+ million active installations according to wordpress.org. Last week a new version was released where one of the changelog entries is “Improved security on calls to opcache flush”. Notable it didn’t claim that any vulnerabilities were fixed in that, but if you were relying on other data sources on vulnerabilities in WordPress plugins you were told that there were two ones fixed related to that change, which clearly shows that these other data sources don’t actually confirm or validate claimed vulnerabilities before adding to their data set.
The changelog for the latest version of the WordPress plugin Ultimate FAQ is “Fixes a minor possible XSS issue”, we don’t know where the possible part comes from since that fixes a vulnerability and when we contacted the developer about that vulnerability we offered to provide them a proof of concept that confirmed that vulnerability was in fact exploitable. Vulnerabilities being inaccurately referred to as a possible or potential vulnerability isn’t an uncommon issue. By comparison the changelog for the latest version of Custom Field Suite is “Fix: prevent possible XSS for logged-in editors or admins (props reddy.io)” and what was fixed there would actually be a described as a possible vulnerability, since it involves allowing those users to do something they normally are permitted to do anyway due to them normally having the “unfiltered_html” capability.
Yesterday we wrote about the web security company Sucuri overstating the impact of a SQL injection vulnerability, which they had re-discovered a year and half after we had discussed it. That was one of two claimed SQL injection vulnerabilities they disclosed recently and the post on the other, claimed to be in the plugin Advance Contact Form 7 DB, manages to be worse.
Last Tuesday we disclosed an arbitrary file upload vulnerability in the plugin WooCommerce Checkout Manager caught through our proactive monitoring of changes made to plugins in the Plugin Directory to try to catch serious vulnerabilities, so not surprisingly the customers of our service were also warned about it then. On Thursday we noted on Twitter that we had seen probing for usage of the plugin that was likely coming from hackers. If you were relying some other product or service to let you know about vulnerable WordPress plugins you likely were late in getting notified of that, since many of those use data from the WPScan Vulnerability Database. When it was belated added to their data set on Friday a couple of things stuck out to us, one being that we were not listed as a reference:
On April 5 due to our proactive monitoring of changes made to plugins in the Plugin Directory to try to catch serious vulnerabilities we disclosed an arbitrary file upload vulnerability we spotted in the plugin SupportCandy. A week after our disclosure Christian Angel independently found the vulnerability. The vulnerability was fixed on April 17.