For years, Mika Epstein has been causing problems for the WordPress community in their role as the head of the WordPress Plugin Review team, which controls the WordPress Plugin Directory. Thankfully, they have now left the team for largely unexplained reasons. Before they did that, they brought in new team members without allowing the WordPress community to be involved in the process. That is in line with the decidedly non open source nature of that team, which hasn’t produced good results in so many ways (one example being vulnerable plugins being pulled and returned without the vulnerabilities being fixed).

As Mika Epstein was leaving, 6 new members of the team were announced. Considering the problems with the existing team’s security reviewer, who remains on the team, we were curious to see if new security expertise was being brought in. Looking over the new team members’ WordPress profiles, we didn’t see any indications of that. But we did run across one of them with a plugin that it was fairly easy to spot as containing vulnerabilities and another concerning issue.

Now that a new team is in place, vetting has been added that Mika Epsten couldn’t have passed and you it is reasonable to wonder if that vetting was done with the new members added. Here is how they explained that:

Given the nature of the work the team does, joining this team is a little different than some of the others: each new member will go through a vetting process by current team members before being selected. Some of the things the team is looking for are: a solid track record as a plugin developer; the ability to communicate clearly, kindly and constructively – both with other developers and users; interest in improving tools and processes; and excellent collaborative and conflict-management skills.

Undisclosed Ownership Change

The plugin Easy Forms for Mailchimp, which is from a new member of the team, has 100,000+ installs. If you visit its page on the WordPress Plugin Directory, you are told that it is from YIKES, Inc.:

Contrary to that, on May 23, that company responded to an inquiry about a claimed unfixed vulnerability in the plugin, saying they are no longer involved in the plugin:

Our plugin business was acquired by EH Dev Shop. https://www.yikesinc.com/eh-dev-shop-acquires-yikes-plugins/

We are no longer involved with selling or supporting the plugins.

The post they linked to is from October 1 of last year and yet the new developer still hasn’t updated the developer information.

Ownership of WordPress plugins changing hands without it being disclosed is a security concern, as a new developer might not handle security well and introduce vulnerabilities (as has happened in the past) or might introduce malicious code in to the plugin (as has happened in the past as well). A lack of disclosure happened with one of the most popular security plugins. The new developer has a track record or poor security (but so did the old one).

It took the developer, who again is a new member of the Plugin Review Team, several weeks to address the claimed vulnerability.

Basic Security Missing

That a member of the team that is in part supposed to be reviewing new plugins to make sure they don’t contain security issues and deal with existing plugins that have known security issues, have that situation seems less than ideal. But taking a quick look at the current state of the plugin, we found it is still missing basic security.

A common area of security issues in plugins and one that is frequently a part of widely exploited vulnerabilities is insecure AJAX accessible functions. There are quite a few such functions in this plugin. Let’s look at one of those, save_field_label_edits(), which is located in the file /admin/partials/ajax/class.ajax.php. The functions in that file are for “functionality on the admin side (ie. Adding new field to form, updating fields, grabbing list data etc”. By default, only users with the Administrator role have access to the plugin’s admin functionality.

That function is registered to be accessible to anyone logged in to WordPress:

36

add_action( 'wp_ajax_save_field_label_edits', array( $this, 'save_field_label_edits' ), 10, 1 );

What should be at the beginning of the function is a capabilities check to make sure only the intended users have access, but that isn’t anywhere in the function:

190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226

public function save_field_label_edits() {
 
	// Capture our $_POST variables
	$list_id	= isset( $_POST['list_id'] ) ? $_POST['list_id'] : '';
	$field_data = isset( $_POST['field_data'] ) ? $_POST['field_data'] : array();
	$field_name = isset( $field_data['field_name'] ) ? $field_data['field_name'] : '';
	$field_id	= isset( $field_data['field_id'] ) ? $field_data['field_id'] : '';
 
	// Make sure we have our required variables before continuing
	if ( $list_id === '' || $field_name === '' || $field_id === '' ) {
		wp_send_json_error( array(
				'message' => __( 'Could not update the field label: missing required field.', 'yikes-inc-easy-mailchimp-extender' ),
				'developer-info' => "One of the following variables was empty: list_id: $list_id, field_name: $field_name, field_id: $field_id."
			)
		);
	}
 
	// Update the field!
	$merge_field = yikes_get_mc_api_manager()->get_list_handler()->update_merge_field( $list_id, $field_id, array( 'name' => $field_name ), true );
 
	// Check for an error. If error, log it and return error
	if ( is_wp_error( $merge_field ) ) {
		$error_logging = new Yikes_Inc_Easy_Mailchimp_Error_Logging();
		$error_logging->maybe_write_to_log( 
			$merge_field->get_error_code(), 
			__( "Updating merge field", 'yikes-inc-easy-mailchimp-extender' ), 
			"class.ajax.php"
		);
		wp_send_json_error( array(
				'message' => __( 'Could not update the field label: API request failed.', 'yikes-inc-easy-mailchimp-extender' ),
				'developer-info' => $error
			)
		);
	}
 
	wp_send_json_success();
}

So anyone logged in to WordPress has access to the function, instead of only Administrators, which is a vulnerability.

There is also a lack of a nonce check to prevent cross-site request forgery (CSRF), so an attacker could cause someone with access to function to cause it to be used without them intending it. That is another vulnerability.

Vetting?

That plugin is tied for the second most popular plugin from one of the new members of the Plugin Review Team. Yet it appears its security wasn’t reviewed by someone familiar with checking the security of WordPress plugins before this person was brought in to the team. That same team member is also one of the developers of the most popular plugin by a team member. In May, we warned about a vulnerability in that plugin after seeing what might have been hacker targeting the plugin.

For new applicants to the team, one of the things they need to provide is:

Provide links to at least three plugins that you coded yourself, or to which you contributed significantly. If a plugin has other contributors, please explain your role.

It’s unclear why someone would need to have been involved in more than one plugin, but one of the new members only has one plugin listed as being a contributor from their profile. That plugin also only had one release.