One of the big problems with keeping up with vulnerabilities in WordPress plugins these days, is that many of the reports of claimed reports of vulnerabilities recently are false reports. If you are getting your data from us, we weed out those reports, but with other data providers they are not only failing to do that, but they are incentivizing more of those reports.

What could explain, in part, the reason why they are including those, beyond inflating the number of vulnerabilities they claim to know about, is that they are not doing the due diligence they should and in one case, claim to be doing. When you don’t do that due diligence there are serious problems, including missing real vulnerabilities that you would have found when checking on a false report and telling people that a real vulnerability has been fixed, when it hasn’t.

Another problem with this activity is if you want to argue that these false reports are real, then you can end up being told that issue has been fixed when it hasn’t. That is the case with the company Patchstack and a recent false report. Last week we explained why a report of a vulnerability in the plugin WPFront Notification Bar was false this way:

A claimed stored cross-site scripting (XSS) vulnerability in the plugin WPFront Notification Bar has the same issue that many recent false reports have had, the attacker would need to be logged in to WordPress as an Administrator.

While there wasn’t a vulnerability, the code could have been better secured, but that would be difficult since there isn’t an easy way to sanitize or escape CSS code, which is what was at issue here. While it would have been easy enough to use the relevant escaping function when it was output on the plugin’s setting page, esc_textarea(), when the CSS code is used it would be different story. After we had come across that report, we had contacted the developer to let them know it was out there and mentioned that.

According to Patchstack the vulnerability was fixed in version 1.9.2 of the plugin:

But if you look at the changes made what was done, there was to add esc_textarea() on the settings page, which had no impact when the CSS code is output as part of the notification bar:

151
152
153

protected function custom_css() {
	echo $this->options->custom_css();
}

This was something that the developer of the plugin was aware of (they told us they made the change they did there to avoid the WordPress Plugin Directory team closing the plugin), but Patchstack seems to have not understood that.

One explanation of that is they simply looked at the changelog and saw this:

XSS fix on the settings page.

What lends credence to that explanation is that they list version it being fixed in as 1.9.2, which is what the version is listed in the changelog, but if you had the plugin installed for testing, you would see that the version is 1.9.2.07163.

Not only is relying on the information in changelogs not a good idea, since it often isn’t accurate, but Patchstack claims to provides “virtual patches” for every vulnerability in their Patchstack Vulnerability Database, which seems hard to deliver on if they are not actually do basic due diligence with these vulnerabilities.

WPScan’s Security Theater

While another provider, WPScan, spread this false report, they are at least not falsely claim the vulnerability was fixed in that version. But they are engaged in security theater, as they have this message with their report:

The PoC will be displayed on July 26, 2021, to give users the time to update.

If you look at the original report, which they link to twice, it provided a proof of concept (that’s all it provided), so them not displaying a proof of concept now doesn’t “give users the time to update”.

Plugin Security Scorecard Grade for Patchstack

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

Plugin Security Scorecard Grade for WPScan

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