The unfortunate reality when it comes to WordPress plugins is that there are lots of security issues in them, so even if the people on the WordPress side of things were not working against improving security there would be lots of problems. As an example of that, when the latest version of the plugin Patreon WordPress showed up in our monitoring of changes made to plugins that might involve security vulnerabilities being fixed we found a serious vulnerability unrelated to change we then were looking into. The change made that caused it to appear on our radar doesn’t seem related to a vulnerability, but in looking into that we happened across a PHP object injection vulnerability, which is a type of vulnerability that more advanced hackers have been known to exploit widely, that is in the current version on the plugin.

The line we noticed that might have allowed PHP object injection (located in the file /classes/patreon_routing.php):

316

$state = unserialize(base64_decode(urldecode($wp->query_vars['state'])));

That takes user input, in the form of part of a URL, and runs it through the unserialize function, which could lead to PHP object injection. What would determine if there was a vulnerability would be how that code could be accessed.

That code is in the function parse_request(), which not all that surprisingly runs when WordPress is parsing the request:

14

add_action( 'parse_request', array( $this, 'parse_request' ) );

The vulnerable code will run if the URL being request includes “/patreon-authorization/” and there is URL parameter “code” included as well:

303
304
305
306
307
308
309
310
311
312
313
314
315
316

if ( strpos( $_SERVER['REQUEST_URI'], '/patreon-authorization/' ) !== false ) {
 
	// First slap the noindex header so search engines wont index this page:
	header( 'X-Robots-Tag: noindex, nofollow' );
 
	// Make sure browsers dont cache this
	header( 'cache-control: no-cache, must-revalidate, max-age=0' );			
 
	if( array_key_exists( 'code', $wp->query_vars ) ) {
 
		// Get state vars if they exist
 
		if( $wp->query_vars['state'] !='' ) {
			$state = unserialize( base64_decode( urldecode( $wp->query_vars['state'] ) ) );

So the vulnerable code is easily accessible, the only thing stopping even easier exploitation is that you need to know of malicious input that could abuse that type of vulnerability, which is out there, though not easily used from what we have seen of the more limited exploitation of this type of vulnerability versus an arbitrary file upload vulnerability.

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. Hopefully they 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).

With this type of vulnerability full disclosure is of more concern, unless you are the people on the WordPress side of things seeing as we full disclosed the same type of vulnerability in a plugin with 30 times the number of installs three weeks ago and the only action they took was to delete our notification for the developer. For some reason, despite them claiming to be concerned about security they are fine with websites using a plugin they know is very vulnerable. If you used our service you would have been warned about that vulnerability when we first disclosed the vulnerability, if you are relying on other plugin vulnerability data sources you might not.

Proof of Concept

With our plugin for testing for PHP object injection installed and activated, the following proof of concept will cause the message “PHP object injection has occurred.” be shown.

Make sure to replace “[path to WordPress]” with the location of WordPress.

http://[path to WordPress]/patreon-authorization/?code=test&state=TzoyMDoicGhwX29iamVjdF9pbmplY3Rpb24iOjA6e30=

Concerned About The Security of the Plugins You Use?