One of the things that you get when using our data on vulnerabilities in WordPress plugins either through our long time service or our new newsletters instead of trying to do things on your own or using lower quality data sources, is that we actually check over the reports and provide an accurate information on them. For a fair amount of reports the original discloser has provided inaccurate information about the vulnerability (or there isn’t even a vulnerability).

One area we see a lot of confusion, whether it be with members of the security community or hackers is with arbitrary file viewing and local file inclusion (LFI) vulnerabilities. A recent example where things got quite mixed up and where other data sources would have lead you astray involved two vulnerabilities disclosed by Manuel Garcia Cardenas a couple of weeks ago.

He disclosed a local file inclusion vulnerability in the plugin Localize My Post, but his proof of concept is for some reason actually a proof of concept that would be used if there was an arbitrary file viewing vulnerability:

GET /wordpress/wp-content/plugins/localize-my-post/ajax/include.php?file=../../../../../../../../../../etc/passwd

Inclusion refers to causing the code in a file to run, but with that proof of concept you would cause the contents of a file that stores username/password info for some operating systems to run, which doesn’t make sense.

If you look at the code at issue it is clearly a local file inclusion vulnerability, as user input is used to specify a file to be included:

include($_REQUEST['file']);

The other vulnerability was also labeled as a local file inclusion vulnerability, this time in the plugin Wechat Broadcast.

With other data sources, that claim was repeated.

Here for example is the WPScan Vulnerability Database repeating the claim (as reported by someone from the website wpscans.com, which is a service that runs WPScan):

And here is WPCampus:

If you look at the code where the vulnerability exists though, the function the user input is passed into doesn’t involve inclusion:

echo file_get_contents(isset($_GET["url"]) ? $_GET["url"] : '');

Here is the PHP documentation for that function,  file_get_contents():

file_get_contents — Reads entire file into a string

So that code doesn’t cause inclusion, but instead will output the contents of  specified file or URL, which is what we refer to as an arbitrary file viewing vulnerability.

The proof of concept for that actually makes sense then since it involves outputting the contents of that username/password file:

GET /wordpress/wp-content/plugins/wechat-broadcast/wechat/Image.php?url=../../../../../../../../../../etc/passwd

The implications of those two types of vulnerabilities are quite different, so getting that wrong makes a big difference.

When these data sources can’t get the type of vulnerability right it shouldn’t be surprising that they provide inaccurate information that is more concern, like falsely claiming that vulnerabilities have been fixed when they haven’t.