Recently in the monitoring we do of third-party data of possible hacker activity related to WordPress plugins, we noticed probing for usage of the plugin ImportWP by making request like this:

 /wp-content/plugins/jc-importer/resources/js/edit.js

There are requests for that logged with abuseipdb.com from May and June.

We didn’t already have listings for any vulnerabilities in the plugin in our data set and we didn’t find any public reports of vulnerabilities, so we went to look over the code to see if there was a vulnerability that we should be warning any customers of our service that are using are plugin about.

What we found is that the plugin is insecure in a number ways, but also that the plugin’s functionality and its code is rather convoluted, making it hard to figure out what a hacker might be trying to exploit. But so that we can warn our customers of a vulnerability in it and highlight that it isn’t secure, let’s look at a security vulnerability that we did confirm exists in it.

The plugin registers the function init() in the file /jc-importer.php to run during “init”, so whenever WordPress is loaded:

128

add_action( 'init', array( $this, 'init' ) );

In that file if is_admin() is true an instance of the class IWP_Admin will be created:

176
177
178
179
180
181
182
183
184
185
186
187

if ( is_admin() || ( defined( 'DOING_AJAX' ) && DOING_AJAX ) ) {
 
	// load importer.
	$importer_id = isset( $_GET['import'] ) && ! empty( $_GET['import'] ) ? intval( $_GET['import'] ) : 0;
	if ( $importer_id > 0 ) {
		$this->importer = new IWP_Importer( $importer_id );
	}
 
	require_once __DIR__ . '/libs/class-iwp-imports-list-table.php';
 
	require_once __DIR__ . '/libs/class-iwp-admin.php';
	new IWP_Admin( $this );

is_admin() can be true even if a request comes from someone not logged in to WordPress.

That class, which is defined in the file /libs/class-iwp-admin.php, will register its function process_forms() to run during “wp_loaded”, so whenever WordPress is loaded:

23

add_action( 'wp_loaded', array( $this, 'process_forms' ) );

In that function no security checks are done before running its code. Part way through the function several GET inputs are sent to variables:

187
188
189

$action   = isset( $_GET['action'] ) && ! empty( $_GET['action'] ) ? $_GET['action'] : 'index';
$importer = isset( $_GET['import'] ) && intval( $_GET['import'] ) > 0 ? intval( $_GET['import'] ) : false;
$template = isset( $_GET['template'] ) && intval( $_GET['template'] ) > 0 ? intval( $_GET['template'] ) : false;

If the “action” input is set to “trash” the value of the “import” input will be used to delete a specified WordPress post:

246
247
248
249
250

if ( $action == 'trash' && ( $importer || $template ) ) {
 
	if ( $importer ) {
 
		wp_delete_post( $importer );

WordPress posts are used to store a variety of data, not just blog posts. Since the post to be deleted is specified by integer, by iterating through those everything stored as a post could be deleted.

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 delete the specified post.

Make sure to replace “[path to WordPress]” with the location of WordPress and “[POST ID]” with ID of the post to be deleted.

http://[path to WordPress]/wp-admin/admin-post.php?action=trash&import=[POST ID]

Concerned About The Security of the Plugins You Use?