Earlier today an unfixed arbitrary file upload vulnerability in the WordPress plugin MStore API  was disclosed through release of exploit code for it. While the information provided with the exploit code claims the vulnerability impacts 2.0.6 and “possibly higher”, the vulnerability actually didn’t exist in that version, but does exist in the latest version of the plugin (information on which versions of the plugin are impacted is included in the data provided by our service). Earlier today the developer made a change that looks like it was an attempt to fix this, while not raising the version number of the plugin, so anyone already using the latest version of the plugin wouldn’t be provided with the attempted fix. That doesn’t matter much, as the change doesn’t fix the issue, just makes exploiting a bit more complicated.

As of posting this, the plugin remains in the WordPress Plugin Directory despite the plugin having a publicly known vulnerability that is of a type hackers are very likely to exploit.

In addition to customers of our service being warned about the vulnerability if they are using the plugin, testing confirmed that our new Plugin Vulnerabilities Firewall plugin, which is included with our service, was already protecting against the exploitation done with the exploit code before that code was released (and equally protects with the modified exploitation needed after the attempted fix was made).

Looking at the underlying code that leads to this vulnerability, it seemed likely that wasn’t the only vulnerability in the plugins. Our Plugin Security Checker flags the possibility of another less serious arbitrary file upload variant. Another more serious issue though came up while we started checking on that. It turns out that anyone logged in to WordPress is able to delete arbitrary files from the website. That also could be exploited through cross-site request forgery (CSRF).

We would recommend not using this plugin unless the developer is able to show that they are capable of properly securing the plugin going forward.

Authenticated Arbitrary File Upload

The plugin registers the function mstore_delete_json_file() to be accessible through WordPress’ AJAX functionality to anyone logged in to WordPress:

103

add_action( 'wp_ajax_mstore_delete_json_file', array( $this, 'mstore_delete_json_file' ) );

That function, which is located in the file /mstore-api.php, does no security checks before deleting a file specified with the GET or POST input “id”:

128
129
130
131
132
133
134
135

function mstore_delete_json_file(){
	$id = $_REQUEST['id'];
	$uploads_dir   = wp_upload_dir();
	$filePath = trailingslashit( $uploads_dir["basedir"] )."/2000/01/".$id;
	unlink($filePath);
	echo "success";
	die();
}

That will normally delete a file located in the directory “/wp-content/uploads/2000/01/”, but through directory traversal, any directory can be accessed.

Testing confirmed that our Plugin Vulnerabilities Firewall plugin will prevent a user from exploiting this vulnerability unless they are an Administrator (who could normally already accomplish this with the access they have).

As one of the missing security checks is checking for a valid nonce, an attacker could cause someone logged in to WordPress to exploit this without intending it through CSRF.

WordPress Causes Full Disclosure

As a protest of the moderators of the WordPress Support Forum’s continued inappropriate behavior we changed from reasonably disclosing to full disclosing vulnerabilities for plugins in the WordPress Plugin Directory 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. (For plugins that are also in the ClassicPress Plugin Directory, we will follow our reasonable disclosure policy.)

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).

If the moderation is cleaned up, it would also allow the possibility of being able to use the forum to start discussing fixing the problems caused by the very problematic handling of security by the team running the Plugin Directory, discussions which they have for years shut down through their control of the Support Forum.

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. Other data providers often fail to really determine if the vulnerability has been fixed.

Proof of Concept

The following proof of concept will delete the file test.txt in the root directory of the website, when logged in to WordPress.

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

http://[path to WordPress]/wp-admin/admin-ajax.php?action=mstore_delete_json_file&id=../../../../test.txt

Concerned About The Security of the Plugins You Use?