In reviewing changes being made to WordPress plugins used by our customers that are supposed to fix vulnerabilities, we often find that the vulnerabilities haven’t actually been fixed. Telling our customers that vulnerabilities have been fixed when we don’t actually know if they have been fixed would be unethical, but that is what we keep finding another provider, Wordfence, is doing with their Wordfence Intelligence Vulnerability Database. On their homepage, Wordfence call themselves the “Global Leaders in WordPress Security” and say you should trust them because of that. It’s unclear what would make someone the global leaders in WordPress security, but we can say they can’t be trusted whether they are the global leaders or not, as what we found below shows.

The changelog for the latest version of the WordPress plugin Simple Calendar claimed that a vulnerability was fixed in the plugin:

Fixed: Cross Site Request Forgery (CSRF) vulnerability.

Wordfence parroted that claim and wrote this:

This makes it possible for unauthenticated attackers to clear the plugin’s transients for a given id, via a forged request granted they can trick a site administrator into performing an action such as clicking on a link.

Looking at the changes being made to the plugin in that version, we found that not only was the changelog description not accurate as to what was at issue, but we found that the issue still exists. We also found multiple vulnerabilities related to the change being made still existed.

Security Checks Still Missing

The change referenced in the changelog involves the function clear_cache() in the file /includes/admin/ajax.php. That function is registered by the plugin to be accessible to anyone logged in to WordPress through its AJAX functionality:

31

add_action( 'wp_ajax_simcal_clear_cache', array( $this, 'clear_cache' ) );

There should be two basic security checks in the function. One to check to make sure only the intended WordPress users have access and a nonce check to prevent cross-site request forgery (CSRF). It had neither of those as of the previous version:

49
50
51
52
53
54
55
56

public function clear_cache() {
 
	$id = isset( $_POST['id'] ) ? ( is_array( $_POST['id'] ) ? array_map( 'intval', $_POST['id'] ) : intval( $_POST['id'] ) ) : '';
 
	if ( ! empty( $id ) ) {
		simcal_delete_feed_transients( $id );
	}
}

The new version only added the nonce check, as mentioned by the changelog:

49
50
51
52
53
54
55
56
57
58
59

public function clear_cache() {
	if(!wp_verify_nonce($nonce,'simcal')){
		return;
	}
 
	$id = isset( $_POST['id'] ) ? ( is_array( $_POST['id'] ) ? array_map( 'intval', $_POST['id'] ) : intval( $_POST['id'] ) ) : '';
 
	if ( ! empty( $id ) ) {
		simcal_delete_feed_transients( $id );
	}
}

While a nonce check will usually do the equivalent of a capabilities check to limit access to the current WordPress users, the WordPress documentation is clear it shouldn’t be used for that:

Nonces should never be relied on for authentication, authorization, or access control. Protect your functions using current_user_can(), and always assume nonces can be compromised.

So a capabilities check still needs to be added to that function.

In the same file, two other AJAX accessible functions are still lacking that capabilities check and another one is still lacking both security checks.

Wordfence’s Inaccurate Claims About Vulnerability

Contrary to what Wordfence claimed, previously, an attacker could have caused anyone logged in to WordPress to take the action, not just site administrators. Also, anyone logged in to WordPress could have done it themselves. But it turns out that even those not logged in can still do this, which Wordfence missed.

Another part of the change being made in the new version, modified the function bulk_actions() in the file /includes/admin/post-types.php. That is registered in a way that makes it accessible to even those not logged in to WordPress:

42

add_action( 'admin_init', array( $this, 'bulk_actions' ) );

The first part of that function will be familiar, as it does the same thing as the clear_cache() function shown before:

155
156
157
158
159
160
161
162
163
164
165
166
167
168

public function bulk_actions() {
 
	// Clear an individual feed cache.
	// @todo Convert the clear cache request to ajax.
	if ( isset( $_REQUEST['clear_cache'] ) ) {
 
		$id = intval( $_REQUEST['clear_cache'] );
 
		if ( $id > 0 ) {
			simcal_delete_feed_transients( $id );
		}
 
		wp_redirect( remove_query_arg( 'clear_cache' ) );
	}

That code still lacks both security checks, so even those not logged in to WordPress can take the action that Wordfence was claiming could only be accomplished by tricking a site administrator.

Another Vulnerability Only Partially Fixed

Further code in that function led to another vulnerability that had existed and was only partially fixed. In the new version, code that allows duplicating the plugin’s calendar feeds was modified to add a capabilities check. Here is how that looks now:

170
171
172
173
174
175
176
177
178
179
180
181
182

	// Duplicate a feed post type.
	if ( isset( $_REQUEST['duplicate_feed'] ) ) {
		if(!current_user_can( 'edit_posts' )){
			wp_redirect( remove_query_arg( 'duplicate_feed' ) );
		}
		$id = intval( $_REQUEST['duplicate_feed'] );
 
		if ( $id > 0 ) {
			$this->duplicate_feed( $id );
		}
 
		wp_redirect( remove_query_arg( 'duplicate_feed' ) );
	}

That still lacks a nonce check to prevent CSRF.

We have notified the developer of the remaining issues and offered to help them address them.

Avoiding Providers Cutting Corners

Wordfence claiming that vulnerabilities have been fixed when they haven’t is a common issue. We have been running instances of Wordfence falsely claiming vulnerabilities have been fixed since they began publicly disclosing this data last year. They are unfortunately not alone in that, in January, we highlighted another example were Wordfence, as well as WPScan and Patchstack claimed a vulnerability had been fixed when it hadn’t. That situation highlights the danger of this, as that still unfixed vulnerability was widely exploited three months after Wordfence said it had been fixed.

Data on WordPress plugin vulnerability is of little use if the data isn’t accurate, so you want to make sure that the data is actually being validated if you are going to be relying on it. The problem is that providers often lie about what they are really doing. Often in a way that is easy to spot if you are familiar with this data, but not easy for the average end user. There is a new option to help end users, as the Certified WP Security program allows reputable providers to get a certification that they are really providing what they claim to offer.