Earlier today, we had an apparent hacker probing our website to see if we were using the WordPress plugin Cookie Information with this request:

/wp-content/plugins/wp-gdpr-compliance/Assets/js/front.min.js

That plugin has 100,000+ installs according to WordPress’ data.

What would explain a hackers interest in the plugin?

Yesterday, a new version was released that has a changelog that simply says “Security improvements.”

There was actually only one change made. In the function execute() in the file /WordPress/Ajax/AbstractAjax.php, the following code was added:

61
62
63

if ( !static::isPublic() && !current_user_can('manage_options') ) {
	static::returnError(__('You do not have sufficient permissions to access this page.', 'vo-gdpr-compliance'));
}

That code restricts access to some functionality in the plugin to only those who have the manage_options capability. That is something normally only users with the Administrator role have.

A hacker would have to dig in further to figure out what the implications of that are. Or not. Yesterday, Wordfence told them what they could do with that:

The Cookie Information | Free GDPR Consent Solution plugin for WordPress is vulnerable to arbitrary option updates due to a missing capability check on its AJAX request handler in versions up to, and including, 2.0.22. This makes it possible for authenticated attackers, with subscriber-level access or higher, to edit arbitrary site options which can be used to create administrator accounts.

(The vulnerability was added to the plugin in version 2.0.)

The change made could only possibly address a missing capability check. It didn’t make any change that would limit updating arbitrary WordPress options, which the plugin really shouldn’t allow.

It wasn’t hard for us to find the relevant code that Wordfence was referencing and how it could be exploited. The code exists in the function buildResponse() in the file /WordPress/Ajax/UpdateIntegration.php. It does indeed allow updating arbitrary WordPress options:

61
62
63
64
65
66
67
68
69
70
71

public static function buildResponse( $data = [] ) {
	$meta_key   = explode( '[', $data['name'] );
	$success    = false;
	$data_value = $data['value'];
 
	switch ( count( $meta_key ) ) {
		case 1:
			$meta_key = reset( $meta_key );
			$settings = $data_value;
			$success  = update_option( $meta_key, $settings );
			break;

While the code doesn’t make it obvious how this can be exploited. The code is used by the Integrations portion of the plugin’s settings. Someone can see how that works and then reuse it maliciously very easily. It only took us a few minutes to create a proof of concept to confirm this was exploitable. With this, anyone logged in to WordPress could, among other things, create new a WordPress account with the Administrator. So they could easily take over the website.

While the update limits updating arbitrary options to Administrators, so there isn’t still a vulnerability. The code should limit what options can be updated, to avoid the possibility of serious security issues like what existed before. We have reached out to the developer to let them know they should limit what options can be updated.

Making the insecurity stand out more is that the plugin previously had this type of vulnerability that was exploitable to even those not logged in to WordPress. Back in November 2018, it was exploited.

The good news for our customers, is that our firewall plugin already blocked standard attempts to exploit this type of vulnerability before this vulnerability was even disclosed through its zero-day protection.