Automattic owned security service WPScan is marketed with the claims that they provide “Enterprise-strength WordPress protection for everyone” and that they have a “dedicated team of WordPress security experts”. The reality is very different.

Among many issues we run across with their data is that they are frequently falsely claiming that plugins have had vulnerabilities, in situations where, say, the claimed vulnerability involves an action taken by an Administrator that the plugin is intended to allow and still allows after the supposed vulnerability has been fixed.

Things can run the other way, where they are claiming something that isn’t a vulnerability is a vulnerability, while there really is a vulnerability they failed to note.

Recently they released a vague report of a claimed vulnerability in the plugin Popup Maker, which has 700,000+ installs based on WordPress’ stats. This was the only detail provided:

The plugin does not sanitise and escape some of its Popup 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

As at least one of our customers was using the plugin, we took a look at this and couldn’t figure out what was going on. That seemed to be referring to the plugin’s Settings page in the admin area of the website, but we couldn’t cause what they were describing to occur in the version before it was supposed to be fixed.

There was a proof of concept they were holding back, so we waited for that to be released to further look in to this. That proof of concept, which has now been released, states is as follows:

Popup Maker > Create Popup > Popup Settings > Triggers > Add New Cookie > Add > Cookie Time, overwrite the default ‘1 month’ with the following XSS payload: <script>alert(‘XSS’);</script>

Click ‘Update’ and Save/Update the Popup. The XSS will be triggered when editing the popup again

So they were not talking about something in the plugin’s Settings page, but something in the Create Popup page, but that doesn’t make sense with the rest of what was written.

As can easily seen by simply logging in to WordPress as user with the Contributor role, users down to that level have access to the Create Popup page. WPScan claimed they verified this, but must not have even done that.

The more technical explanation of who had access, which security experts should have looked into, is that access to that is controlled by the what is specified in the registration for the post type used for that:

50

register_post_type( 'popup', apply_filters( 'pum_popup_post_type_args', $popup_args ) );

25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

$popup_args = apply_filters( 'popmake_popup_post_type_args', array(
	'labels'              => $labels,
	'public'              => true,
	'publicly_queryable'  => false,
	'query_var'           => false,
	'rewrite'             => false,
	'exclude_from_search' => true,
	'show_in_nav_menus'   => false,
	'show_ui'             => true,
	'menu_icon'           => pum_get_svg_icon( true ),
	'menu_position'       => 20.292892729,
	'supports'            => apply_filters( 'popmake_popup_supports', array(
		'title',
		'editor',
		'revisions',
		'author',
	) ),
	'show_in_rest'        => pum_get_option( 'gutenberg_support_enabled', false ), // Adds support for Gutenberg currently.
) );

What that shows is that it doesn’t specify capabilities required, so the defaults are used. So user with the edit_posts capability would have access to that.

Further checking confirmed that was explained in the proof of concept was exploitable by Contributors.

What WPScan was describing isn’t really a vulnerability, as should be obvious to security experts. Administrators have the ability to do almost anything, so they would normally have multiple routes to edit a plugin’s file and remove security code like was added to address this. But it would be a vulnerability for low-level users to be able to do that and somehow WPScan, while claiming they verified this, didn’t even do basic checking to see who had access to that.

Someone trying to assess the security risk caused by that, which someone working for an enterprise might, wouldn’t be able to properly do that if they relied on what WPScan had claimed about the access needed to exploit this.

The information from the developer wasn’t better here, as when noted the fix in the changelog, they wrote this:

Improvement: Add precautionary escaping of some generated outputs.

That would match with the issue WPScan is claiming was here, but not the reality of it.

The inaccurate claims were given a CVE ID, CVE-2022-1104, despite not being a vulnerability as described.

Plugin Security Scorecard Grade for WPScan

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