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.

Admin+ Stored Cross-Site Scripting in Broken Link Checker

Automattic’s WPScan claimed there had been an admin+ stored cross-site scripting via import vulnerability in the plugin Broken Link Checker. They explained it this way:

The plugin does not sanitise and escape some of its settings, which could allow high privilege users such as admin to perform Stored Cross-Site Scripting attacks even when the unfiltered_html capability is disallowed (for example in multisite setup)

Presumably they were trying to refer to users with the Administrator role there.

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:

382
383
384
385
386
387

$options_page_hook = add_options_page(
	__( 'Link Checker Settings', 'broken-link-checker' ),
	__( 'Link Checker', 'broken-link-checker' ),
	'manage_options',
	'link-checker-settings',
	array( $this, 'options_page' )

The saving of the settings is run through that page and there is a nonce check to prevent cross-site request forgery (CSRF), which would allow an attacker to cause someone to take an action they didn’t intend, before saving the settings:

476
477

if ( isset( $_POST['submit'] ) ) {
	check_admin_referer( 'link-checker-options' );

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.

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

Admin+ SQLi in HTML Forms

Automattic’s WPScan claimed there had been an admin+ SQLi vulnerability in the plugin HTML Forms. They explained it this way:

The plugin does not properly properly escape a parameter before using it in a SQL statement, leading to a SQL injection exploitable by high privilege users

Based on the name of the vulnerability, presumably they were trying to refer to users with the Administrator role there.

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, one of the plugin’s admin pages. That page requires a capability only given to Administrators:

4

$wp_roles->add_cap( 'administrator', 'edit_forms' );

The underlying code that handles the action happening in the proof of concept checks for the same capability and there is a nonce check to prevent cross-site request forgery (CSRF), which would allow an attacker to cause someone to take an action they didn’t intend, before saving the settings:

94
95
96

if ( ! isset( $_REQUEST['_wpnonce'] ) || ! wp_verify_nonce( $_REQUEST['_wpnonce'], '_hf_admin_action' ) ) {
	wp_nonce_ays( $action );
	exit;

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.

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

Reflected Cross-Site Scripting in Download Manager

Automattic’s WPScan made this claim about a supposed reflected cross-site scripting vulnerability in the plugin Download Manager:

The plugin does not escape the $_SERVER[‘REQUEST_URI’] parameter before outputting it back in an attribute of the modal login page (only available when users are not logged in), which could lead to Reflected Cross-Site Scripting in old web browsers.

So what web browsers would those be? They don’t say.

That might have to do with the fact that modern web browsers encode characters in URLs, which restricts this being a vulnerability, as well as any web browsers following the standard related to that, RFC 3986. Unless they can point to a reasonable scenario where this would be exploitable, this would be more accurately described as a possible or a potential vulnerability.

Plugin Security Scorecard Grade for Download Manager

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