Yesterday, we noted that the WordPress security provider WPScan isn’t verifying claimed vulnerabilities being added to their data set, despite claiming to do just that. That came in the context of them claiming that there was a vulnerability in a plugin, where what they claimed was at issue wasn’t really a vulnerability, but there really was a more serious vulnerability. That wasn’t a one-off issue.

WPScan recently claimed that the plugin Popup Maker had contained an admin+ stored cross site scripting vulnerability, which they described this way:

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

As described, that wouldn’t be a vulnerability since Administrators can basically do whatever they want. Testing the proof of concept tells a different story about what was really possible.

The proof of concept involved creating a new popup for the plugin and then following a sequence of steps. We found that it was possible to do those things logged in as an Administrator, but it was also possible do that with users that don’t have the unfiltered_html capability (or the ability to re-add that capability as Administrators normally would). That isn’t hard to check on, as you could simply log in as a low-level user and see they have the access needed, which WPScan didn’t do, despite claiming they “figure out what kind of privilege is required to successfully exploit the issue”.

Just to confirm that, we checked the underlying code and confirmed that when the custom post type being accessed is registered, it is done without specifying a capability required, so it defaults to the “post” capability:

25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56

$popup_args = apply_filters(
	'popmake_popup_post_type_args',
	[
		'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',
			[
				'title',
				'editor',
				'revisions',
				'author',
			]
		),
		'show_in_rest'        => pum_get_option( 'gutenberg_support_enabled', false ), // Adds support for Gutenberg currently.
	]
);
 
// Temporary Yoast Fixes
if ( is_admin() && isset( $_GET['page'] ) && $_GET['page'] === 'wpseo_titles' ) {
	$popup_args['public'] = false;
}
 
register_post_type( 'popup', apply_filters( 'pum_popup_post_type_args', $popup_args ) );

That makes it accessible to anyone able to create a WordPress post, so normally down to Contributors.

This was given the CVE ID CVE-2022-3690, despite, as described, not really being a vulnerability.

Patchstack’s Lack of Verification

With the vulnerability we discussed yesterday, Patchstack doesn’t have it in their data set, but with the vulnerability, they do. Patchstack markets their data this way:

Hand curated, verified and enriched vulnerability information by Patchstack security experts. Find all WordPress plugin, theme and core security issues.

The second part of that isn’t true, since they don’t have the other vulnerability (or many others) in their data set, but the first part claims they verify things and provide “enriched vulnerability information”, whatever that is. They also claim they “hand curate” information, again, whatever that means. Yet their listing for this incorrectly claims the required access level is:

Requires high role user authentication like admin.

That isn’t correct, so they didn’t verify things as they claim to do.