Cross-Site Scripting vulnerability in Email Users WordPress Plugin

Abstract

A Cross-Site Scripting vulnerability was found in the Email Users WordPress Plugin. This issue allows an attacker to perform a wide variety of actions, such as stealing Administrators' session tokens, or performing arbitrary actions on their behalf. In order to exploit this issue, the attacker has to lure/force a logged on WordPress Administrator into opening a malicious website.

OVE ID

OVE-20160712-0012

Tested versions

This issue was successfully tested on Email Users WordPress Plugin version 4.8.2.

Fix

This issue is resolved in Email Users version 4.8.3.

Introduction

The Email Users WordPress Plugin allows a WordPress user to send an email to the registered blog users. Users can send personal emails to each other. Power users can email groups of users and even notify group of users of posts. A Cross-Site Scripting vulnerability was found in the Email Users WordPress Plugin. This issue allows an attacker to perform a wide variety of actions, such as stealing Administrators' session tokens, or performing arbitrary actions on their behalf. In order to exploit this issue, the attacker has to lure/force a logged on WordPress Administrator into opening a malicious website.

Details

The issue exists in the file email_users_user_settings.php and is caused by the lack of output encoding on the page request parameter. The vulnerable code is listed below.

<form id="email-users-filter" method="get">
	<!-- For plugins, we also need to ensure that the form posts back to our current page -->
	<input type="hidden" name="page" value="<?php **echo $_REQUEST['page']** ?>" />
	<!-- Now we can render the completed list table -->
	<?php $mailusersListTable->search_box(__('Search', MAILUSERS_I18N_DOMAIN), 'search_id'); ?>
	<?php $mailusersListTable->display() ; ?>
</form>

Normally, the page URL parameter is validated by WordPress, which prevents Cross-Site Scripting. However in this case the value of page is obtained from $_REQUEST, not from $_GET. This allows for parameter pollution where the attacker puts a benign page value in the URL and simultaneously submits a malicious page value as POST parameter.

Proof of concept

<html>
	<body>
		<form action="http://<target>/wp-admin/admin.php?page=mailusers-user-settings" method="POST">
			<input type="hidden" name="page" value="&quot;<script>alert(document.cookie);</script>" />
			<input type="submit" value="Submit request" />
		</form>
	</body>
</html>

Questions or feedback?