On Friday we noted in our post detailing a reflected cross-site scripting (XSS) vulnerability in the WordPress plugin Ninja Forms, which has 1+ million active installations according to wordpress.org, that our Plugin Security Checker,  which is a tool that allows anyone to see if there are possible security issues in WordPress plugins that could use further investigation, had been updated to better catch that type of issues like that based on variations that existed in that plugin’s code from how things are normally done.

We were also interested in seeing if there were other popular plugins that might have similarly vulnerable code that had yet to be have been caught by anyone due those variations, so we ran the updated check from the Plugin Security Checker over the 1,000 most popular plugins in the WordPress Plugin Directory. What we found was there are a number of those plugins that look like they might be vulnerable, though most of them didn’t contain the variations, so our Plugin Security Checker would have already spotted them.

We took a look at two of the most popular plugins, both with 80,000+ installations, with the possible issue and found that both were in fact vulnerable. That is yet another good reason to check plugins you use through our Plugin Security Checker since it will alert you if plugins you use possibly contain a similar issue (and possibly contain more serious vulnerabilities). From there if you are a paying customer of our service you can suggest/vote for it to receive a security review that will check over that or you can order the same type of review separately.

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 a previously full disclosed vulnerability was 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.

Anti-Spam by CleanTalk

In plugin Anti-Spam by CleanTalk the issue appears to exist in several places, but we happened to check the following line in the file /inc/cleantalk-comments.php:

88

<input id="ct_date_range_from" class="ct_date" disabled="disabled" readonly="readonly" type="text" value="<?php echo isset($_GET['from']) ? $_GET['from'] : ''; ?>" />

That code will output the value of the GET input “from” without escaping it, which is a reflected cross-site scripting (XSS) vulnerability, if it exists, when visiting the plugin’s “Find spam comments” admin page.

Proof of Concept

The following proof of concept will cause any available cookies to be shown in an alert box, when logged in as an Administrator. 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/edit-comments.php?page=ct_check_spam&from="><script>alert(document.cookie);</script>

KingComposer

In the plugin KingComposer there are two lines of code that are potentially vulnerable, but one of them doesn’t lead to a vulnerability since other code in the same file limits what values can be output. That doesn’t appear to have been done with a thought to security, since several lines later in the code the issue is there again without that type of protection being elsewhere in the code. The issue occurs in the file /includes/extensions/kc.screen.tmpl.php on the following line:

91

<input class="wp-filter-search" name="q" type="search" value="<?php echo isset($_GET['q']) ? $_GET['q'] : ''; ?>" placeholder="<?php _e('Search Extensions', 'kingcomposer'); ?>" aria-describedby="live-search-desc" />

That code will output the value of the GET input “q” without escaping it, which is a reflected cross-site scripting (XSS) vulnerability, if it exists, when visiting the plugin’s “Extensions” admin page.

Proof of Concept

The following proof of concept will cause the any available cookies to be shown in an alert box, when logged in as an Editor. 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?tab&page=kc-extensions&q="><script>alert(document.cookie);</script>

Concerned About The Security of the Plugins You Use?

Plugin Security Scorecard Grade for Anti-Spam by CleanTalk

See issues causing the plugin to get less than A+ grade