On Friday we looked at a vulnerability likely being exploited in a WordPress plugin, where there is a fix, but WordPress hasn’t made it available. Like that situation, we had what appears to be a hacker probing for usage of the plugin Front End Users over the weekend by requesting the readme.txt file for the plugin. Like that previous situation, the plugin is closed on the WordPress plugin directory:

No explanation has been given for the closure there and those already using the plugin are not being warned it was closed. Like the previous situation, Wordfence disclosed the day after the closure that there is a type of vulnerability that hackers would exploit in the plugin. And again, they haven’t made sure that there is a fix available or used their weight to try to make sure that happens before they disclosed the vulnerability. We have offered to make sure there are fixes in those situations for many years, without the offer being taken up by WordPress. Wordfence hasn’t supported our effort or any other effort to make sure that happens.

In the previous post, we quoted Wordfence claiming that vulnerabilities in plugins were “accidents.” But the reality, which Wordfence surely knows, is that many vulnerabilities are the result of certain developers intentionally cutting corners on security. The vulnerability here is an exception to that. It really is an accident.

Wordfence claimed that the plugin “is vulnerable to arbitrary file uploads due to missing file type validation in the file uploads field of the registration form.” Looking at the code, though, it is easy to think that claim is wrong. We thought that at first.

Here is the relevant code, which appears to contain a file type validation before the uploaded file is saved to the website:

351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368

$filetype = wp_check_filetype( $_FILES[$Field_Name]['name'] );
 
if ( $validate['type'] !== false ) {
 
	$upload_dir = wp_upload_dir();
 
	//for security reason, we force to remove all uploaded file
	$target_path = $upload_dir['path'] . '/ewd-feup-user-uploads/';
 
	//create the uploads directory if it doesn't exist
	if (!file_exists($target_path)) {
		  mkdir($target_path, 0777, true);
	}
 
	$Random = EWD_FEUP_RandomString();
	$target_path = $target_path . $Random . basename( $_FILES[$Field_Name]['name']); 
 
	if (!move_uploaded_file($_FILES[$Field_Name]['tmp_name'], $target_path)) {

If you look carefully at the code or you try testing exploitation out after not spotting the problem, you realize what the problem is. There is a file type check done using the wp_check_filetype() function. The problem is that the result of that is set to the variable $filetype and then the code check $validate before saving the file, which doesn’t exist. So the result of the file type check gets ignored.

Fixing this would take only a moment, as you simply need to rename one of the two variables reference to match the other. Yet that hasn’t happened. So websites using the plugin are still open to being hacked.

It is important to note that to do anything further after uploading a malicious file through the vulnerability, the developer would need to know or guess a 10 character random string. That would make this likely to only result in a website being taken over if the website shows the listing of files in directories without an index file (which usually isn’t the case). To upload a file, it looks like the file would need to include a File or Profile Picture field.

Our customers were already protected against exploitation of this since before the vulnerability was disclosed through the zero-day protection in our Plugin Vulnerabilities Firewall.

Free Warning

As the vulnerability is being targeted by a hacker, we are adding accurate data on it to the free data that comes with our Plugin Vulnerabilities plugin.