In reviewing reports of vulnerabilities in WordPress plugins 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 level of getting their own post we now place them in a weekly post when we come across them.

Persistent Cross-Site Scripting (XSS) Vulnerability in Cookie Consent

With a claimed persistent cross-site scripting (XSS) vulnerability in the plugin Cookie Consent the proof of concept didn’t make a lot of sense to us:

1) Access WordPress control panel.
2) Navigate to the ‘Pages’.
3) Add a new page and insert the script you wish to inject into the page title.
4) Now navigate to ‘Settings’ and select ‘Cookie Consent’.
5) Now click on the ‘Content’ tab.
6) Your injected script will now be executed.

It wasn’t at all clear what was supposed to be the connection between the actions in steps 1-3 and the plugin. It turns out there really isn’t any.

What seems to have happened here is that the person behind this doesn’t understand that Administrator level-users (as well as the only other users, Editors, that can create pages by default) normally have the unfiltered_html capability, which allows them to do the equivalent of cross-site scripting (XSS). In this situation if at step four you had instead visited the page created in steps 1-3 the script would also run, so other than this occurring on an admin page the same result would occur without the plugin.

If a user could create new pages and didn’t have the unfiltered_html capability they wouldn’t be able save a script to a page’s title in the first place, so there wouldn’t be an issue when the plugin’s page is accessed.

Persistent Cross-Site Scripting (XSS) Vulnerability in Responsive Cookie Consent

The person behind that claim made also made a claim of the same type of vulnerability in the plugin Responsive Cookie Consent, which we found on another data source of plugin vulnerabilities, the WPScan Vulnerability Database, which doesn’t do the same type of checking we do before adding claimed vulnerabilities.

In this case the claimed vulnerability at least was connected directly with the plugin:

1) Access WordPress control panel.
2) Navigate to the Responsive Cookie Consent plugin page.
3) Select one of the input fields. For example, “Cookie Bar Border Bottom Size”.
4) Insert the script you wish to inject.
5) Save the plugin settings.
6) Injected script will run in the victim user’s browser. Depending on which input field you inserted the script, the script may also run everytime you load the Responsive Cookie Consent plugin page.

As we explained with the previous claimed vulnerability, Administrator level-users are normally have the unfiltered_html capability, which allows them to do the equivalent of cross-site scripting (XSS), so if only they have access to it, it wouldn’t really be a vulnerability. Looking at the code that sets up the admin page for the plugin, we could see that it is limited to those with the “manage_options” capability:

4

add_submenu_page('options-general.php', __('RCC Settings', 'responsive-cookie-consent'), 'RCC', 'manage_options', 'rcc-settings', 'rcc_options_page');

Users with the “manage_options” capability would normally only be Administrators (and if others are given the capability they would normally be able to create Administrators accounts).

There still was the possibility have been an issue if there was a lack of protection against cross-site request forgery (CSRF), but we found that is properly protected against.