Hacker Targeted WordPress Plugin Returns to Plugin Directory Without Update For Exploitable Vulnerability

For years, the handling of security of the WordPress Plugin Directory has been rather poor, caused by a multitude of issues. In addition to the problems with their handling of security, there hasn’t been a willingness to work with the community to address that. One of the two problematic long time leaders of that (and two of only four members overall, somehow) left earlier this year. Notably, as they were leaving, a largely new team was brought in by them without the involvement of the community. So far, the new team doesn’t seem to have been reaching out to those actually interested in helping them improve their handling of security. That isn’t because they are now handling things well now, as yet another problematic situation shows.

In October, we wrote about seeing a hacker targeting a WordPress plugin named Dropshipping & Affiliation with Amazon and finding that the plugin was still in the plugin directory despite having a vaguely disclosed serious vulnerability. The plugin was subsequently closed on the plugin directory.

In the past few days, it was reopened. Curiously, our monitoring system to alert us to check if there are fixes for known unfixed plugin vulnerabilities in our data set, alerted us to it being reopened, but didn’t list there having been a new version released, which is odd. Checking in on this, we found the developer had made an attempt to fix the vulnerability, but hadn’t changed the version number of the plugin. So no one is getting the new version. The plugin is still also vulnerable, because the fix was incomplete.

When we last covered this, we wrote this about the missing security checks in the code relevant to the vulnerability:

There should be multiple security checks in that code, including a nonce check to prevent cross-site request forgery (CSRF) and a limit on what types of files can be uploaded. Another missing security check, which would shut off hackers’ easy ability to exploit this, would be to add a capabilities check to limit access to the intended users. It appears the functionality is only intended to be accessed by users with the “import” capability, which only Administrators normally have.

No nonce check has been added.

There was code added to try to limit what types of files can be uploaded:

$allowed_file_types = array('image/jpeg', 'image/png', 'image/gif'); // Define allowed image types
$file_info = new finfo(FILEINFO_MIME_TYPE);
$file_type = $file_info->buffer($image_data);
if (in_array($file_type, $allowed_file_types)) {

The problem with that is that it can be easily bypassed for a well-known reason. Placing the text “GIF89a” at the beginning of a .php file will cause that code to see the MIME type, which is checked for, as an allowed value, “image/gif”.

The updated code also now calls a capabilities check:

855	if ($this->wpas_is_upload_authorizatied()) {

That calls new function that checks if the user has the upload_files capability:

private function wpas_is_upload_authorizatied()
{
	if (is_user_logged_in()) {
		// Check if the user has the 'import' capability
		if (current_user_can('upload_files')) {
			return true;
		}
	}
	return false;
}

That makes this accessible down to users with the Author role instead only Administrators.

If one of the needed fixes was incomplete or missing, that would be one thing, but none of them has been properly addressed and yet the plugin was allowed back in to the plugin directory.