One of the ways we keep track of possible vulnerabilities in WordPress plugins is to monitor the WordPress Support Forum for discussions related to those. Today, there was a concerning claim of a high risk vulnerability in a plugin that is used by at least one of our customers, as well aa 300,000+ websites, Widgets for Google Reviews. Another user of the plugin was claiming that it contained a “high risk vulnerability as it allows the upload of backdoors”. They also said this was an arbitrary file upload vulnerability. They were not the original source for the claim, instead, it was Patchstack.

Patchstack’s own claims were similar. They, for example, wrote that the claimed vulnerability would “allow a malicious actor to upload any type of file to your website”. It’s only if you click a button labeled “Show technical details” that they bothered to mention a critical detail. The attacker, they say, would need to have the WordPress Editor role or above to exploit this.

What they are therefore describing is an authenticated arbitrary file upload vulnerability. Somehow they left out the “authenticated” part, despite that being a critical detail. It appears they left out another important detail as well.

What they also left out is any information needed to independently confirm their claim.

Strangely, while Patchstack claims that this is high risk vulnerability, 8.1 out 10 using an unreliable severity scoring system, they also said this was “medium priority” vulnerability and that you should “patch within 7 days“. We can’t square those two things. Surely a high risk vulnerability should be addressed immediately. Maybe someone else can. If you can, please leave a comment below.

Any vulnerability that would have to be exploited by a user with the Editor role is of little concern, as it is unlikely that almost any WordPress websites would have an untrusted individual with that level of access who seeks to exploit this. That doesn’t mean that it shouldn’t be addressed and there is insecure code in the plugin that needs to be fixed.

Authenticated Race Condition/Remote Code Execution (RCE)

Checking over the plugin, we found that the plugin’s admin functionality is made accessible to both Administrators and Editors, so that would be a likely place to find the issue described based on the level of access needed. Looking at the underlying code, we found functionality accessed that way that partially matches the claim.

The admin area of the plugin has a section to request a feature be added to the plugin (accessed at /wp-admin/admin.php?page=wp-reviews-plugin-for-google%2Fsettings.php&tab=feature_request), which has a form input intended to be used to upload images:

The underlying code for that functionality will temporarily save the files to the website before an email with them is sent to the developer (the lack of formatting is in the original):

17
18
19
20
21
22
23

if (isset($_FILES['attachments'])) {
$wpUploadDir = wp_upload_dir();
for ($i = 0; $i < count($_FILES['attachments']['name']); $i++) {
$targetFile = $wpUploadDir['basedir'] . DIRECTORY_SEPARATOR . date('YmdHis') . '-' . basename($_FILES['attachments']['name'][ $i ]);
if (@move_uploaded_file($_FILES['attachments']['tmp_name'][ $i ], $targetFile)) {
$attachments []= $targetFile;
}

27
28
29

foreach ($attachments as $attachment) {
@unlink($attachment);
}

There are not any restrictions to limit the files temporarily saved to only be image files.

The files are temporarily saved to a web accessible location, so an attacker could potentially reach them. The files are deleted once an email is sent, though, so an attacker would have a limited amount of time to access them. That is often referred to as a race condition. That limiation isn’t something that Patchstack noted. So what is actually at issue there is what we refer to as authenticated race condition/remote code execution (RCE).

That insecure code exists in other plugins by the developer as well. We confirmed that it is accessible in the plugin Customer Reviews Collector for WooCommerce by Shop Managers, making it a vulnerability, but not Editors.

The developer responded on the support forum that they “are working on resolving the issue as soon as possible”. Patchstack claims they contacted the developer previously about this, but received no reply from the vendor.” We are reaching out to them with our findings and offering to help them address this.

Plugin Security Scorecard Grade for Patchstack

See issues causing the plugin to get less than A+ grade