With recent vulnerabilities in the WordPress plugin ProfilePress (formerly WP User Avatar), we have been ahead the pack, being the first to identify that the new plugin replacing the previous WP User Avatar plugin, was insecure through our proactive monitoring of changes made to plugins in the Plugin Directory to try to catch serious vulnerabilities. We also warned about the more serious vulnerabilities nearly a month before other providers. What we didn’t do is what another data provider, WPScan, has done, run with a false report of a vulnerability in the plugin. Here is the description of a claimed authenticated stored XSS vulnerability they added to their data set two days ago:

The plugin did not sanitise or escape some of its settings before saving them and outputting them back in the page, allowing high privilege users such as admin to set JavaScript payloads in them even when the unfiltered_html capability is disallowed, leading to an authenticated Stored Cross-Site Scripting issue

That description sounds like lots of false reports recently, which would involve an attacker who would have to be logged in to WordPress as an Administrator, which isn’t a vulnerability, since Administrators can already do whatever they want. One of the problems with just ignoring those, is that occasionally there is a more serious vulnerability that gets missed if no one does the due diligence on those.

One of the questions to ask with claims like this, is what WordPress role or capability is necessary to access the supposedly vulnerable code. In this case, the description comes from someone who doesn’t seem too familiar with WordPress or the code in the plugin, as they refer to “high privilege users such as admin” instead of what you would expect here. Looking at the code the plugin’s admin pages are restricted users with the manage_options capability, so Administrators:

28
29
30
31
32
33
34
35
36

add_menu_page(
            esc_html__('ProfilePress - WordPress User Registration & Profile Plugin', 'wp-user-avatar'),
            'ProfilePress',
            'manage_options',
            PPRESS_SETTINGS_SLUG,
            '',
            $this->getMenuIcon(),
            '80.0015'
        );

The report goes on to say that attacker would be able to “set JavaScript payloads in them even when the unfiltered_html capability is disallowed”. There isn’t a reasonable scenario where an Administrator would not have that capability (they have it by default) and be unable to enable it again since they are Administrators.

There could still be an issue if there lack protection against cross-site request forgery (CSRF) or the underlying code handling the saving of the settings isn’t itself properly restricted to Administrators. If either of those were the case, there would be a problem here since the version that was supposed to fix this doesn’t have changes that would resolve either of those.

While the underlying code is incredibly hard to follow, which is concerning, if we followed and tested it right, there is both a capabilities check and nonce check to prevent CSRF before saving the settings (located in the function persist_plugin_settings() in the file /src/Functions/custom-settings-api.php):

245
246
247
248
249
250
251
252
253

if ( ! current_user_can('manage_options')) {
	return;
}
 
if (empty($_POST['save_' . $this->option_name])) {
	return;
}
 
check_admin_referer('wp-csa-nonce', 'wp_csa_nonce');

So no vulnerability. What would make this easier is if the WPScan provided the claimed proof of concept for this, but they are holding that back:

The PoC will be displayed on July 12, 2021, to give users the time to update.

That is a convenient way to make it harder for anyone to confirm the report is false in a timely manner.