Automattic Appears to Have Falsely Claimed That Competing WordPress Security Plugin Contained Reflected XSS Vulnerability

The company closely associated with WordPress, Automattic, has the most popular WordPress security plugin by installs, Jetpack. It has 5+ millions installs according to wordpress.org. Recently another piece of Automattic, WPScan claimed a competing plugin, All In One WP Security, which has 1+ million installs had contained a reflected cross-site scripting (XSS) vulnerability (emphasis ours):

The plugin does not validate, sanitise and escape the redirect_to parameter before using it to redirect user, either via a Location header, or meta url attribute, when the Rename Login Page is active, which could lead to an Arbitrary Redirect as well as Cross-Site Scripting issue. Exploitation of this issue requires the Login Page URL value to be known, which should be hard to guess, reducing the risk

The other issue mentioned there, an open redirect, did exist, though it is a less serious issue.

If how Automattic markets WPScan were true, there shouldn’t be any doubt about the veracity of that claim. As they claim this:

Dedicated team of WordPress security experts

And this:

Enterprise-strength WordPress protection for everyone

As at least one of our customers uses that plugin, we looked into this two weeks ago, and we noted for our customers that the claim seemed suspect:

It is unclear whether there is actually a cross-site scripting (XSS) issue. Looking at the details of the claim and code, it is possible that is only speculation, though we will recheck when the claimed proof of concept is provided.

The XSS issue appears to relate to a situation where headers were already sent before the relevant code runs, as XSS would be possible if the else statement in the function redirect_to_url() in the file /classes/wp-security-utility.php runs:

static function redirect_to_url($url, $delay = '0', $exit = '1')
{
	if (empty($url)) {
		echo "
<strong>Error! The URL value is empty. Please specify a correct URL value to redirect to!</strong>";
		exit;
	}
	if (!headers_sent()) {
		header('Location: ' . $url);
	} else {
		echo '<meta http-equiv="refresh" content="' . $delay . ';url=' . $url . '" />';

No explanation is provided on a situation where that would occur.

WPScan has now provided the proof of concept that is supposed to back that claim up and it doesn’t. The proof of concept provided is this:

https://example.com/xxxxxx?redirect_to=”><script>alert(/XSS/)</script>

In our testing, that simply caused a redirect to https://example.com/”><script>alert(/XSS/)</script>. That isn’t cross-site scripting (XSS), just a redirect to a URL that wouldn’t exist on a website. WPScan claimed that their security experts verified this, but it doesn’t look like that is the case at all.

WPScan appears to have also put this false information in to the CVE system, with the ID CVE-2021-25102.