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+ Reflected Cross-Site Scripting in Smush

A couple of weeks ago Automattic’s WPScan claimed that the plugin Smush had contained an admin+ reflected cross-site scripting vulnerability that involves somehow getting an Administrator to upload a file to their website:

The plugin does not sanitise and escape a configuration parameter before outputting it back in an admin page when uploading a malicious preset configuration, leading to a Reflected Cross-Site Scripting. For the attack to be successful, an attacker would need an admin to upload a malicious configuration file

We were waiting on their proof of concept to see if they made an actual argument about how this was supposed to reasonably occur, but it wasn’t provided. What they are describing is a social engineering attack, which you could cause the same result with no vulnerability.

Looking at the relevant admin page for the plugin, it doesn’t appear that these configuration files are intended to be publicly shared, but instead come from other websites you control:

Use configs to save preset configurations of Smush’s settings, then upload and apply them to your other sites in just a few clicks!

Persistent Cross-Site Scripting in WP Event Manager

With a claimed persistent cross-site scripting vulnerability in WP Event Manager, the instructions are referring to doing something that involves WordPress’ post editor:

1 – First Install the plugins – wp-event-manager and activate it.
2 – Go to event manager —> Add New
3 – Inside the “”Event Title” at the top, enter XSS payload “><img src=x
onerror=alert(1)> and hit publish.
4 – Check the newly made event’s URL /event/{id}/ , XSS will trigger.

What they claim you can do there is only possible if the user doing it has the unfiltered_html capability. If you try it with a user that doesn’t have that capability, that content is removed. The unfiltered_html capability specifically is designed to allow doing that.

Admin+ Stored Cross-Site Scripting in FiboSearch

A claimed admin+ stored cross-site scripting vulnerability in FiboSearch is described 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 when the unfiltered_html capability is disallowed

To access the plugin’s settings, the user has to be logged in as an Administrator:

37
38
39
40
41
42
43
44

add_submenu_page(
	'woocommerce',
	__( 'FiboSearch', 'ajax-search-for-woocommerce' ),
	__( 'FiboSearch', 'ajax-search-for-woocommerce' ) . $menuSuffix,
	'manage_options',
	'dgwt_wcas_settings',
	array( $this, 'settingsPage' )
);

If an attacker is logged in as an Administrator they can do basically whatever they want, including usually allowing the unfiltered_html capability, so this really wouldn’t be a vulnerability.

Even though this isn’t a vulnerability, we recently did a security review of the plugin and should have caught this, since there shouldn’t have been sanitization being done and we want to avoid false vulnerability reports for plugins we review. We checked on what happened and found that the issue was with the developer not properly using the sanitzation_callback of the register_settings() function. We have added checking for that type of issue during our security reviews.

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

Reflected Cross-Site Scripting (XSS) in Code Snippets

Patchstack claimed that the plugin Code Snippets contained a reflected cross-site scripting (XSS) vulnerability. The developer of the plugin provided a pretty good explanation of why this isn’t really a vulnerability:

I have checked through plugin code, and I believe the report to be a false positive. Using the example malicious link they provide, there’s nothing in the plugin code that would actually output the malicious JavaScript on the site.

It does, however, generate a parse error, and so the only way that this could be a genuine XSS vulnerability is on a site where error reporting is set to just directly output error messages on the screen unescaped.

This false report was given a CVE id by Patchstack, CVE-2022-25617, despite not really being a vulnerability. That CVE entry has four references, one of them oddly linking to the plugin’s page on the WordPress plugin directory as somehow confirming this despite not doing that and the developer claiming it is a false positive:

CONFIRM:https://patchstack.com/database/vulnerability/code-snippets/wordpress-code-snippets-plugin-2-14-3-authenticated-reflected-cross-site-scripting-xss-vulnerability
URL:https://patchstack.com/database/vulnerability/code-snippets/wordpress-code-snippets-plugin-2-14-3-authenticated-reflected-cross-site-scripting-xss-vulnerability
CONFIRM:https://wordpress.org/plugins/code-snippets/
URL:https://wordpress.org/plugins/code-snippets/

We notified CVE of that, but they refused to address it. Claiming that we needed to contact Patchstack, despite Patchstack being the ones providing inaccurate information to CVE.

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