Recently, the WordPress security provider Wordfence was criticizing another provider, Patchstack, for incentivizing low quality claims of vulnerabilities in WordPress plugins:

There are an extremely high number of low risk and low quality vulnerabilities being submitted to databases like Patchstack,” he said. “Vulnerabilities that involve a Cross-Site Request Forgery are an example of this. The incentives we are seeing out there encourage researchers to generate a a high volume of low risk vulnerabilities to get rewarded. These high numbers are then used to market security products.”

It was odd criticism as Wordfence itself prominently markets itself with high numbers (emphasis in the original):

Wordfence Intelligence is an industry-leading WordPress vulnerability database and evolving Threat Intelligence platform that contains over 12,000 records for vulnerabilities in WordPress plugins, themes, and core.

Also, as we have noted repeatedly, Wordfence has serious vulnerability data quality issues of its own, which Wordfence simply refuses to acknowledge, much less address.

Their own quality issues come up again with a new claim they made of an authenticated (Editor+) arbitrary file upload vulnerability in one of the most popular WordPress plugins, Contact Form 7. What they are actually describing would possibly be a race condition/remote code execution (RCE) vulnerability, but it isn’t even that. Instead, there was a minor security issue. Calling it a vulnerability isn’t helpful, especially coming from a provider criticizing another provider over handling of real, but minor vulnerabilities.

Wordfence claimed that the issue “makes it possible for authenticated attackers with editor-level capabilities or above to upload arbitrary files on the affected site’s server.” They went on to say that “due to the htaccess configuration, remote code cannot be executed in most cases” and that “by default, the file will be deleted from the server immediately.” What they are describing there is what is referred to as a race condition. As an attacker could possibly race ahead of the file deletion and access the file before it is deleted, causing remote code execution. But can they?

What Wordfence somehow failed to note is that files are not placed in a known location that an attacker could access. Instead, the ultimate directory the file is placed in has a random name generated from a combination of digits 0-9. That is generated with the following code:

297
298
299
300
301
302
303
304
305
306
307
308
309

function wpcf7_maybe_add_random_dir( $dir ) {
	do {
		$rand_max = mt_getrandmax();
		$rand = zeroise( mt_rand( 0, $rand_max ), strlen( $rand_max ) );
		$dir_new = path_join( $dir, $rand );
	} while ( file_exists( $dir_new ) );
 
	if ( wp_mkdir_p( $dir_new ) ) {
		return $dir_new;
	}
 
	return $dir;
}

In our test system, that code created a directory with a 10 digit value, like 2097549459. That would have 10,000,000,000 possible combinations. Wordfence should understand that makes an attacker guessing the location of the file before it is deleted impractical.

The aforementioned Patchstack also is spreading the inaccurate information about this, leading a support forum topic with an alarming title, Arbitrary File Upload Vulnerability. Another data provider, the Automattic owned WPScan, also mislabeled this.

Wordfence made a more serious mistake in what else they said about this claimed vulnerability that suggests they don’t have a great grasp of a common type of vulnerability, which will touch in a follow up post.