In reviewing reports of vulnerabilities in WordPress plugins 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.

Arbitrary File Viewing Vulnerability in Advanced uploader

Last week we wrote about the security community’s problem understanding the basics when it comes to arbitrary file viewing and local file inclusion (LFI) vulnerabilities. We ran across that again with a false report of an arbitrary file viewing vulnerability in the plugin Advanced uploader. On one of our websites we had this attempt from a hacker to try to exploit what they thought was a vulnerability in the plugin:

/wp-content/plugins/advanced-uploader/upload.php?destinations=../../../../../../../../../wp-config.php%00

We didn’t have a vulnerability that seemed to match that already in our data set and in looking at the most recent version of the plugin we didn’t see code that looked like could be related to that.

When we did a search on the path used in the exploitation attempt one of the results was from the WPScan Vulnerability Database:

What is shown there doesn’t make sense. If there was a local file inclusion vulnerability you wouldn’t use it to include the WordPress configuration file as that did, since that file is already included each time WordPress runs. That proof of concept would be relevant if the vulnerability was an arbitrary file viewing vulnerability, not a local file inclusion vulnerability.

That page cites a report located here, which doesn’t actually describe what kind of vulnerability there is supposed to be, so the WPScan Vulnerability Database got the type of claimed vulnerability wrong on their own. The larger issue is that the vulnerability doesn’t exist.

The vulnerability is supposed to be in version 2.10 of the plugin. If you look at the code in the relevant file of that version of the plugin what you will see is that the only time user input “destinations”, which is part of the proof of concept, is used is in places in the code that are not accessible when sending a request directly to the file. It looks like someone might have looked at some of the code and thought there was vulnerability without actually understanding the totality of the code or actually testing things out, considering their proof of concept wouldn’t work (nor would it even make sense for testing purposes).

Arbitrary File Upload Vulnerability in Cnhk Slideshow

We also had a request that looked to be trying to exploit a vulnerability in Cnhk Slideshow recently:

/wp-content/plugins/cnhk-slideshow/uploadify/uploadify.php

There is a report from four years ago that would seem to be related to that, which involves a claim that there is an arbitrary file upload vulnerability in that file (which doesn’t exist in more recent versions of the plugin), but in looking at the code in the file the request would have been sent to, it is clear that the claim is false. Basic details, like the name of the file input used in the code are wrong in the proof of concept. There is also the issue that the code in the file will stop running before even getting to the upload code with the proof of concept provided as this is the first code:

3
4
5
6
7
8
9
10

if (isset($_POST['sid'])) {
	session_id($_POST['sid']);
	session_start();
} else {
    header('Status: 403 Forbidden');
    header('HTTP/1.1 403 Forbidden');
    exit();
}

The proof of concept doesn’t include a POST input “sid” so the rest of code won’t run. Even if you added that input to the request, it would fail at the next check done.