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 WF Cookie Consent

Last week we discussed basically the same exact claimed persistent cross-site scripting vulnerability as is now claimed to be in the plugin WF Cookie Consent with a similarly named plugin Cookie Consent. As with that one the first three steps have no connection with the plugin:

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 ‘WF Cookie Consent’.
5) Your injected script will now be executed.

As with the other claimed vulnerability, 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.