One way we help to improve the security of WordPress plugins, not just for customers of our service, but for everyone using them, is our proactive monitoring of changes made to plugins in the Plugin Directory to try to catch serious vulnerabilities. For some time, we also have run all the code in the plugins used by our customers through that monitoring system on a weekly basis to provide additional protection for them. More recently, we expanded the range of possible security issues that we check over in customer used plugins every week. Through that we caught a reflected cross-site scripting (XSS) vulnerability that was introduced in to the 100,000+ install plugin Squirrly SEO in the last week.

If you are using plugins not already used by our customers, once you start using our service, those plugins will be getting checked on a weekly basis as well.

The possibility of this vulnerability is also flagged by our Plugin Security Checker, so you can check plugins you use to see if they might have similar issues with that tool.

We tested and confirmed that our firewall plugin for WordPress protected against exploitation of this vulnerability, even before we discovered the vulnerability, as part of its protection against zero-day vulnerabilities.

Reflected Cross-Site Scripting (XSS)

In a recent version of the plugin, a new file, /view/FocusPages/Innerlinks.php, was added. A line in that file outputs the result of the WordPress function remove_query_arg() without escaping it:

174

<select name="snum" onchange="location.href = '<?php echo remove_query_arg( array('snum') ); ?>&snum=' + jQuery(this).find('option:selected').val()">

The documentation for that function specifically warns about doing that:

Important: The return value of remove_query_arg() is not escaped by default. Output should be late-escaped with esc_url() or similar to help prevent vulnerability to cross-site scripting (XSS) attacks.

As shown with the proof of concept below, in line with that warning, the lack of escaping permits reflected cross-site scripting (XSS) to occur in the admin area of WordPress.

Subsequently, the same vulnerable code was added to two additional files.

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.

After four years, the moderators have finally tacitly admitted they were behaving inappropriately and have made moves to fix the problems (though incompletely), so these full disclosures can be ended if they simply restore access to our accounts and plugins in the Plugin Directory. Hopefully that takes less than four years.

Proof of Concept

The following proof of concept will cause the message “XSS” to be shown in an alert box, when logged in to WordPress as an Editor and with at least one inner Llink. 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.

http://[path to WordPress]/wp-admin/admin.php?page=sq_focuspages&tab=innerlinks&"><script>alert('XSS');</script>

Concerned About The Security of the Plugins You Use?