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.

PHP Object Injection in White Label CMS

Automattic’s WPScan claimed there was a PHP object injection vulnerability in White Label CMS. 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.

Possibly 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, “Settings > White Label CMS”:

18
19
20
21
22
23
24

$page = add_options_page(
	__('White Label CMS', 'white-label-cms'),		// Page title
	__('White Label CMS', 'white-label-cms'),		// Menu name
	'manage_options', 					// Permissions
	'wlcms-plugin.php',					// Menu slug
	array($this, 'view')                // Function callback
);

In reality and contrary to WPScan’s information, the “attacker” doesn’t need to have access to that page to access the import functionality that was supposed to be vulnerable. But checking the relevant code, they would still need to be an Administrator and there is a nonce check to prevent cross-site request forgery (CSRF) as well. That is handled in the function import() in the file /includes/classes/Settings.php:

159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185

public function import()
{
	if (!isset($_POST['wlcms-settings_nonce'])) return;
 
	if (!is_admin() && !current_user_can('manage_options')) {
		return;
	}
 
	if (!isset($_POST['wlcms-settings']) && !isset($_FILES['import_file'])) {
		return;
	}
 
	if (!isset($_FILES['import_file'])) {
		return;
	}
 
	if ($_FILES['import_file']['size'] == 0 && $_FILES['import_file']['name'] == '') {
		return;
	}
 
	// check nonce
	if (!wp_verify_nonce($_POST['wlcms-settings_nonce'], 'wlcms-settings-action')) {
 
		WLCMS_Queue('Sorry, your nonce did not verify.', 'error');
		wp_redirect(wlcms()->admin_url());
		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-4302, despite not really being a vulnerability.

PHP Object Injection in Ocean Extra

Automattic’s WPScan claimed there was a PHP object injection vulnerability in Ocean Extra. They explained it this way:

The plugin unserialises the content of an imported file, which could lead to PHP object injections issues when a high privilege user import (intentionally or not) a malicious Customizer Styling file and a suitable gadget chain is present on the blog.

It isn’t explained what user would be able to do that or why they would unintentionally import a malicious file.

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, “Appearance > OceanWP > Customizer”. 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.

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