Not Really a WordPress Plugin Vulnerability, Week of January 13

In reviewing reports of vulnerabilities in WordPress plugins to provide our customers with the best data on vulnerabilities in plugins they use, we often find that there are reports for things that don’t appear to be vulnerabilities. For more problematic reports, we release posts detailing why the vulnerability reports are false, but there have been a lot of that we haven’t felt rose to that level. In particular, are items that are not outright false, just the issue is probably more accurately described as a bug. For those that don’t rise to the level of getting their own post, we now place them in a weekly post when we come across them.

Reflected Cross-Site Scripting in Spectra

Automattic’s WPScan claimed there was a reflected cross-site scripting vulnerability in Spectra. They explained it this way:

The plugin does not escape some URLs before outputting them back in attributes, leading to Reflected Cross-Site Scripting

The proof of concept provided is this:

When the admin notice about Usage Tracking is displayed: https://example.com/wp-admin/index?a”><script>alert(/XSS/)</script>

The proof of concept doesn’t explain when that situation would be true. Looking at the relevant code in the plugin, it looks like that admin notice would never be shown as the functionality it is part of isn’t called by the plugin, so there really wasn’t a vulnerability.

Admin+ PHP Object Injection in Anti-Malware Security and Brute-Force Firewall

Automattic’s WPScan claimed there was a reflected cross-site scripting vulnerability in Anti-Malware Security and Brute-Force Firewall. They explained it this way:

The plugin unserializes user input provided via the settings, which could allow high privilege users such as admin to perform PHP Object Injection when a suitable gadget is present.

Presumably they were trying to refer to users with the Administrator role, but that would mean this isn’t really a vulnerability, so who knows.

The proof of concept shows that the “attacker” would need to be logged in as an Administrator based on the page they would be accessing, the plugin’s settings page:

if (is_multisite())
	$GLOBALS["GOTMLS"]["tmp"]["settings_array"]["user_can"] = "manage_network";
elseif (!isset($GLOBALS["GOTMLS"]["tmp"]["settings_array"]["user_can"]) || $GLOBALS["GOTMLS"]["tmp"]["settings_array"]["user_can"] == "manage_network")
	$GLOBALS["GOTMLS"]["tmp"]["settings_array"]["user_can"] = "activate_plugins";

We checked the underlying code and there is a nonce check to prevent cross-site request forgery (CSRF) here. So a logged in Administrator would have to intentionally do what is claimed to be a vulnerability. A logged in Administrator normally could do the equivalent of this, so it isn’t really a vulnerability.

The page for this entry has disappeared from WPScan’s website.

This false report was given a CVE id by WPScan, CVE-2022-4327, despite not really being a vulnerability.