_{Wordfence is putting WordPress website at risk by disclosing vulnerabilities in plugins with critical details needed to double check their work missing, in what appears to be an attempt to profit off of these vulnerabilities. We are releasing those details so that others can review the vulnerabilities to try to limit the damage Wordfence’s practice could cause.}

Wordfence didn’t provide any description of the vulnerability beyond that it was a reflected cross-site scripting (XSS) vulnerability in Easy Forms for MailChimp version 6.1.2, but it was easy to spot with just that information.

Before we get in to the details of the vulnerability we wanted to highlight something we noticed in their post that seems to speak to them trying present themselves as being more professional than they really are, that also has the (intended?) impact of misleading public as to the severity of the vulnerability discussed.

In the post Wordfence included a severity score for the vulnerability, on a scale of 0-10, with 10 being the highest. The score they gave this vulnerability was “8.8(High)”. The reality is that based on our dealing with lots of hacked website, this vulnerability is very unlikely to be exploited on the average website and all of the major web browsers other than Firefox have long included XSS filtering that would limit the ability to successfully exploit this type of vulnerability if someone were actually to try. If this is high severity vulnerability, it is hard to image what type of vulnerability they would consider even to be of medium severity. Inflating low severity vulnerabilities isn’t helpful to improving the security of WordPress, since if the public doesn’t have a good understanding of what the real risks are they can’t make informed decisions on how to best protect themselves from them.

Strangely Wordfence gave it such a high score despite having mentioned in the paragraph preceding the severity score one of the major limitations of this type of vulnerability:

It is important to note that many modern browsers, such as Chrome and Safari, protect against these types of scripts running on the client side, which diminishes the odds that this vulnerability will be exploited in the wild.

Getting back to the details of the vulnerability, when looking at the changes made in the version that fixed this, 6.1.3, the vulnerability is easy spot.

In the file /admin/partials/menu/options.php in version 6.1.2 the GET input “error_message” is echoed out without escaping it first:

79

<p><?php _e( urldecode( $_GET['error_message'] ) , 'yikes-inc-easy-mailchimp-extender' ); ?></p>

In version 6.1.3 it is now escaped through esc_attr:

79

<p><?php echo esc_attr( urldecode( $_GET['error_message'] ) , 'yikes-inc-easy-mailchimp-extender' ); ?></p>

Proof of Concept

The following proof of concept will cause any available cookies to shown in alert box when logged in to WordPress. 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.php?page=yikes-inc-easy-mailchimp-settings&error_log_created=false&error_message=<script>alert(document.cookie);</script>