It looks like a hacker has recently been probing for the WordPress plugin Limb Gallery by requesting the file /wp-content/plugins/limb-gallery/js/angular-touch.min.js. In reviewing the plugin we so far haven’t found an obvious vulnerability that hackers might be interested in exploiting. That may be due to a lot of code being bunched together instead clearly separated out. Our Plugin Security Checker did identify the possibility of a less serious vulnerability, which we confirmed, so we can warn any customer of our service that are using the plugin of that vulnerability and let them know there may be a more serious issue.

The plugin runs all of is AJAX functionality through one function, grsGalleryAjax(), instead of separating it out and makes the function available to those logged in as well as those not logged in:

92
93

add_action( 'wp_ajax_grsGalleryAjax', array( &$this, 'grsGalleryAjax' ) );
add_action( 'wp_ajax_nopriv_grsGalleryAjax', array( &$this, 'grsGalleryAjax' ) );

That function loads the file /ajax/GRSGalleryAjax.php, creates a new instance of the class GRSGalleryAjax, and the runs the function grsCheckAction() in that class:

229
230
231
232
233
234

public function grsGalleryAjax() {
	require_once( GRS_PLG_DIR . '/ajax/GRSGalleryAjax.php' );
	// Check nonce
	$object = new GRSGalleryAjax;
	$object->grsCheckAction();
}

If the GET or POST input “grsAction” is set to “shortcode” that will cause the function display() in the file /admin/views/ViewShortcode.php to run. In that file the value of the GET input “task” is to the $task variable without being sanitized:

26

$task = isset($_GET['task']) ? $_GET['task'] : '';

That is then output without being escaped:

47

var task = '<?php echo $task; ?>',

Which is a reflected cross-site scripting (XSS) vulnerability.

WordPress Causes 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. 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.

http://[path to WordPress]/wp-admin/admin-ajax.php?action=grsGalleryAjax&grsAction=shortcode&task=</script><script>alert(document.cookie);</script>

Concerned About The Security of the Plugins You Use?