It’s a bad look when a major WordPress security provider is disclosing that one of their own plugins has a serious security issue, which happened six months ago with the developer of iThemes Security. It’s even worse when the code is so insecure, which was also the case with iThemes. Automattic, the company of the head of WordPress Matt Mullenweg, which provides security solutions under brands including WPScan and Jetpack, today fixed a serious vulnerability in one of their plugins. That this happened runs counter to the view we see often that Automattic are security experts, but in line with previous security issues with their software. Unlike the situation with iThemes, though, this isn’t known to be a zero-day (a vulnerability being exploited before the developer knows about it) and doesn’t involve a security failure at such a basic level. It does involve having incredibly insecure code running in a situation that is high risk.

With that said, this situation could be used as impetus to finally move WordPress plugin security to a better place. But first, let’s look at what went wrong here.

The changelog entry for the impacted plugin, WooCommerce Payments, doesn’t indicate the seriousness of the issue, as it only says “Update – Security update.”, but a post on WooCommerce’s blog labeled it a “Critical Vulnerability”. That plugin has 500,000+ installs. The update is being applied automatically, which should limit the damage from the vulnerability.

Looking at the changes made in the new version makes it easy to understand what is at issue (so we are not disclosing anything competent hackers wouldn’t easily understand by discussing it). In the plugin’s main file, this code was removed:

30
31
32
33
34
35
36
37
38

require_once __DIR__ . '/includes/platform-checkout/class-platform-checkout-session.php';
 
use \WCPay\Platform_Checkout\Platform_Checkout_Session;
 
/**
 * Needs to be loaded as soon as possible
 * Check https://github.com/Automattic/woocommerce-payments/issues/4759
 */
Platform_Checkout_Session::init();

That causes the file /includes/platform-checkout/class-platform-checkout-session.php to be loaded and the code in it is run. Alongside that, the file that was loaded there was removed from the plugin.

In that file, there is code that registers for the function determine_current_user_for_platform_checkout() to be used to determine what is the current WordPress user:

25

add_filter( 'determine_current_user', [ __CLASS__, 'determine_current_user_for_platform_checkout' ] );

That function allows user input in the form of an HTTP header to specify what the current user is:

36
37
38
39
40
41
42
43
44
45
46

public static function determine_current_user_for_platform_checkout( $user ) {
	if ( $user ) {
		return $user;
	}
 
	if ( ! isset( $_SERVER['HTTP_X_WCPAY_PLATFORM_CHECKOUT_USER'] ) || ! is_numeric( $_SERVER['HTTP_X_WCPAY_PLATFORM_CHECKOUT_USER'] ) ) {
		return null;
	}
 
	return (int) $_SERVER['HTTP_X_WCPAY_PLATFORM_CHECKOUT_USER'];
}

So an attacker sending the right request would be treated as whatever WordPress user they want. Normally the account with ID 1 is an Administrator, so specifying 1 in the relevant user input would allow them to be an Administrator and do whatever they want with the website.

How did someone write code that insecure? It seems possible that they didn’t understand the implication of relying on $_SERVER[‘HTTP_X_WCPAY_PLATFORM_CHECKOUT_USER’] to determine what the user is.

What is more concerning is that Automattic didn’t detect this vulnerability themselves, instead “Michael Mazzolini of GoldNetwork” is credited. It also wasn’t caught promptly, as it has been in the plugin since the end of September.

Better Results in the Future

We hope that this will be a wake-up call to Automattic that they are not handling security well, but previous issues haven’t. We also hope that this would be a wake-up call to Matt Mullenweg that WordPress plugin security needs to be handled better in a systematic way through WordPress, but his company’s security brands profit off of the insecurity and his direct employees have been allowed to poorly run the WordPress Plugin Directory for years, so that seems unlikely.

If there was an interest from Matt Mullenweg to improve things, then having a large scale review of usage of the determine_current_user filter, used in that code, in other plugins, to make sure other plugins don’t have a similar issue, would be a good start.

For us, we are adding checking usage of the determine_current_user filter to our security reviews of WordPress plugins, so we can make sure to catch any issue like that when we review the security of WordPress plugins going forward. As we mentioned earlier this week, lots of WordPress plugins could use a security review, but are not getting them.

Plugin Security Scorecard Grade for WPScan

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