In reviewing reports of vulnerabilities in WordPress plugins to provide our customers with the best data on vulnerabilities in plugins they use we often find that there are reports for things that don’t appear to be vulnerabilities. For more problematic reports we release posts detailing why the vulnerability reports are false, but there have been a lot of that we haven’t felt rose to that level. In particular are items that are not outright false, just the issue is probably more accurately described as a bug. For those that don’t rise to level of getting their own post we now place them in a weekly post when we come across them.

Local File Inclusion Vulnerability in WP Staging

The report of a claimed local file inclusion vulnerability in the plugin WP Staging is the kind of strange report we have never understood what might be the explanation of, as you have someone subtly modifying real code from a plugin to present a very different situation from reality.

The report lists the vulnerable file as /index.php, the actual file is /apps/Backend/views/tools/index.php. The report shows that two lines of code are the cause of this:

30:require_once $this->path . “views/tools/tabs/” . $activeTab . “.php”;
5: $activeTab = $_GET[‘tab’] : “import_export”;

The first of those is largely accurate, as this is how the line actually looks:

30

<?php require_once $this->path . "views/tools/tabs/" . $activeTab . ".php"?>

The second line though is very different:

5

$activeTab  = (isset($_GET["tab"]) && array_key_exists($_GET["tab"], $tabs)) ? $_GET["tab"] : "import_export";

What they removed is very important since it limits the values of the variable $activeTab, which is used in the previous line, and that prevents local file inclusion. We thought it might be that while the report listed the version impacted as 2.4.8 they were actually looking at an earlier version of the plugin when the code was different, but the older versions don’t look like that either and are not vulnerable either.

Cross-Site Request Forgery/File Upload in Jssor Slider

Now in a reoccurring part of these posts we are pointing out that someone going by the handle is “KingSkrupellos” is getting more false reports listed with Packet Storm. This time it turned out that they copied a real report of ours from June of 2016 of an arbitrary file upload vulnerability in Jssor Slider that we noted had already been fixed and claimed that it was a cross-site request forgery/file upload vulnerability in the most recent version. The plugin has been changed significantly since our disclosure and it doesn’t even contain similar code anymore, so this wasn’t a situation where there could be any confusion over it being fixed or being possible in the latest version.