Not Really a WordPress Plugin Vulnerability, Week of January 27

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+ SQLi in Website File Changes Monitor

Automattic’s WPScan claimed there had been an admin+ SQLi vulnerability in the plugin Website File Changes Monitor. They explained it this way:

The plugin does not sanitise and escape user input before using it in a SQL statement via an action available to users with the manage_options capability (by default admins), leading to an SQL injection

So if that is accurate, there wouldn’t be a vulnerability unless there was a cross-site request forgery (CSRF) issue there, as Administrators can already do the equivalent of SQL injection intentionally. The proof of concept suggests that CSRF wasn’t an issue, as it says “The nonce required for the header “X-WP-Nonce”.

Checking the underlying code, we can see that this is indeed limited to Administrators as the “manage_options” capability is required to access the claimed vulnerable functionality:

register_rest_route(
	WFCM_REST_NAMESPACE,
	self::$mark_read_dir,
	array(
		'methods'             => WP_REST_Server::DELETABLE,
		'callback'            => array( $this, 'delete_events_within_folder' ),
		'permission_callback' => function () {
			return current_user_can( 'manage_options' );

As it involves a REST API route with a permission_callback, CSRF would be protected against as well.

There was a SQL statement that wasn’t properly secured. We checked for any others that were still insecure and it looked like that had been the only one.

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

Admin+ Stored XSS in Simple Basic Contact Form

Automattic’s WPScan claimed there had been an admin+ stored XSS vulnerability in the plugin Simple Basic Contact Form. 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, but that would mean this isn’t really a vulnerability, so who knows?

Looking at the plugin’s code, access to where the attacker would have to be able to access to exploit this is limited to Administrators:

1126	add_options_page($scf_plugin, esc_html__('Contact Form', 'scf'), 'manage_options', __FILE__, 'scf_render_form');

So this wouldn’t really be a vulnerability, as an Administrator could normally re-allow the unfiltered_html capability if it is disallowed.

The change that was supposed was to have fixed this doesn’t properly address the real security issue that has existed there. As there was improper sanitization and there still is. For the mentioned email setting in the proof of concept provided, the sanitization was changed from:

1046	$input['scf_email'] = sanitize_text_field($input['scf_email']);

1046	$input['scf_email'] = esc_attr($input['scf_email']);

The relevant sanitization function for an email address, though, is sanitize_email(). No sanitization is even done for another email setting. We have notified the developer of that.

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

Admin+ SQLi in SiteGround Security

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

The plugin does not properly sanitize user input before using it in an SQL query, leading to an authenticated SQL injection issue.

That would imply that anyone logged in to WordPress could do that, which would be a vulnerability. The claimed type of vulnerability, though, would suggest possibly it was limited to Administrators, which wouldn’t be a vulnerability. The proof of concept shows a request being sent to a REST API route:

/wordpress/index.php/wp-json/sg-security/v1/activity-registered

The relevant REST API route registration shows that to access that, a user would have to have the activate_plugins capability, which is limited to Administrators:

register_rest_route(
	self::REST_NAMESPACE, '/activity-registered/', array(
		'methods'             => 'POST',
		'callback'            => array( $this->activity_helper, 'registered_activity' ),
		'permission_callback' => array( $this, 'check_permissions' ),
	)
);

As it involves a REST API route with a permission_callback, cross-site request forgery (CSRF) would be protected against as well, so there wasn’t really a vulnerability there.

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